Increase online security using SSO to centralize IAM and MFA

Whether you are developing cloud based applications or accessing lots of different corporate applications and web properties daily, there is a clear advantage to streamlining your security profile using SSO

What is SSO authentication.

Single Sign-on authentication is designed to improve your online security posture by centralizing identity management and multi factor authentication.

The result is that employees of an organisation can use one set of sign in credentials to get access to all the corporate applications, web sites and data they have permission to access.

The employee gains time and simplicity by only having one set of credentials to manage and the enterprise or organisation benefits by adopting better security and compliance methodology that can lead to lower overheads in terms of support and management of employee security.

SSO works based on a trust relationship between an identity provider (IdP) and a service provider being the application or website requiring authentication.

Lots of applications require regular password changes which adds to the potential for users to lose or forget passwords when they are required to maintain individual usernames and passwords for all the different corporate applications they need to use on a day to day basis.

SSO providers typically provide the ability for users to change their passwords on demand, while the centralised nature of SSO management means the IT department does not need to get involved in day to day password management, but can easily provision or remove users across the entire corporate application landscape in one place, which is a massive time saving from an IT support perspective.

The concept of centralized digital identity management is also referred to as federated identity. Federated identity management revolves around several key concepts.

Authentication - handling the validation of user credentials and the identity of a user.

Authorization - sets access permissions or restrictions per federated user.

Attributes - manages common values or attributes (like the user's name) that may be used in different linked applications. Federation links fields to a central value, so that duplication of common attributes or field values is avoided. Changing the attribute value once, propagates the change to all the linked application fields.

User management - provides the ability to create, update and delete users across multiple applications from a central management location.

SSO is primarily related to the authentication stage. SSO will establish the identity of a user and pass that information to each application requiring the authenticated credentials.

The major benefit and time saver with SSO is that once you have logged in to one application or web property, you are automatically logged in to any other application or web property connected to your SSO authentication service.

From a technical perspective session information is made available between different applications using a variety of methods. The way SSO providers capture and share browser or session token data differs between providers. Some providers for instance will use an encrypted signed JSON web token that is generated by a central domain and stores all the information required by other domains for authentication purposes.

This works by domains using centralized authentication redirecting log in requests to the centralized primary domain. If a user is already logged in at that central domain, the user can be redirected back to the requesting application domain with the necessary authentication token allowing them access without having to re-enter login credentials.

There are many different SSO providers with differing requirements should you wish to integrate SSO into your applications like:

OpenID Connect (OIDC)

“OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.”

Facebook Connect

“Facebook Login is a fast and convenient way for people to create accounts and log into your app across multiple platforms. It's available on iOS, Android, Web, desktop apps and devices such as Smart TVs and Internet of Things objects. Facebook Login enables two scenarios, authentication and asking for permissions to access people's data. You can use Facebook Login simply for authentication or for both authentication and data access.”

SAML

“Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions). SAML is also:

A set of XML-based protocol messages

A set of protocol message bindings

A set of profiles (utilizing all of the above)

An important use case that SAML addresses is web-browser single sign-on (SSO). Single sign-on is relatively easy to accomplish within a security domain (using cookies, for example) but extending SSO across security domains is more difficult and resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardized to promote interoperability.”

oAuth 

oAuth is an open standard using token based authentication and authorization to provide SSO.

OAuth was co-developed by Google and Twitter to enable streamlined internet logins. OAuth uses a similar methodology as SAML to share login information. SAML provides more control to enterprises to keep their SSO logins more secure, whereas OAuth is better on mobile and uses JSON.Facebook and Google are two OAuth providers that you might use to log into other internet sites.

Okta

Okta is a customizable, secure drop-in solution to add authentication and authorization services to your applications.

You can connect any application in any language or on any stack to Okta and define how you want your users to sign in. Each time a user tries to authenticate, Okta will verify their identity and send the required information back to your app.

Use SDKs or the API to connect your apps, add users, configure rules, customize your sign-in page, and then monitor your services from built-in reports.

Okta allows you to define both SAML and OIDC apps to implement SSO

How does SSO improve security?.

So a common misconception is that the danger with SSO is that since only one password is required, once that is obtained by an unauthorised person, they then have access to all the systems connected. The truth is most people re-use passwords across different sites, so are in the same position anyway. Typically when a user has access to SSO, they will use a more complex password, since they only need to enter it once.

The attack surface is also reduced as anyone key-logging or intercepting network traffic only has one point of attack and not dozens of applications or websites available to compromise.

When SSO is utilised, mutli-factor authentication is also more likely to be used. Combining a single daily log in that is combined with SMS or authenticator app verification is infinitely more secure than single stand alone log in points.

How does SSO decrease IT costs?

In a corporate environment, over half of all help desk calls can be related to password or log in issues. The more applications and websites a user is required to access for their job, the more load is placed on support staff. A Gartner report put the number of password related support desk calls at well over 50%.

The issue hasn’t been helped by the trend towards insisting on longer more complex passwords, so implementing SSO removes many of these problems and reduces support overheads.

How do organisations benefit from SSO?

Employees may be required to log into multiple applications and web properties on an hourly basis. When SSO is implemented, you gain an instant lift in productivity as users don’t need to spend time logging in or searching around for forgotten passwords. Users also enjoy a better flow as they seamlessly move between applications without interruption.

If you require customers to sign in to your systems like an e-commerce platform, providing SSO removes potential friction when the customer needs to sign in to the checkout page resulting in fewer cart abandonments due to forgotten passwords.

Securing your Hava account with SSO

You can now use SSO to better protect access to the data and diagrams in your Hava account. SSO is currently in beta release for business account users and can be enabled for your account by contacting support@hava.io

Setting up Hava to use SSO is a simple process, however you will need to be the account owner.

Adding a Provider

To connect to your SSO provider, go to your account settings and select SSO Config to get started. 

Currently SAML and OIDC are supported however several other platform specific apps are under development.

1. 1.

   Log into Hava and head to your Account Settings. From there select SSO Config, then click SAML on the protocol selection page. This will show you the Service Provider values you will need to enter into Okta

2. 2.

   Log into Okta and click Applications → Create App Integration

3. 3.

   Select SAML 2.0 and click Next

4. 4.

   Name the app Hava and click Next

5. 5.

   Use the Service Provider values from the Hava SSO SAML section to complete the fields on this page:

   1. 1.

      Single Sign on URL is Assertion Consumer Service URL
   2. 2.

      Audience URI is Issuer (Entity ID)
   3. 3.

      Default RelayState is also Issuer (Entity ID)
   4. 4.

      Name ID format is set to EmailAddress

6. 6.

   Leave the rest as is and click Next

7. 7.

   Select Okta customer and click Finish

8. 8.

   Click View Setup Instructions to see the information required for Hava

9. 9.

   Head back to the Hava SSO SAML config page and select Add SAML Config

10. 10.

    Enter the config values from the Okta setup instructions:

    1. 1.

       Identity Provider Entity ID is Identity Provider Issuer
    2. 2.

       Identity Provider SSO URL is Identity Provider Single Sign-On URL
    3. 3.

       Public x509 Certificate is X.509 Certificate

11. 11.

    Click Save to complete the setup

You can now either test the login via your Okta App page, or by heading to the Login URL displayed in the Service Provider details in Hava. Once you have confirmed the configuration works you can then Enable your provider to limit logins to SSO only for your account.

 

OKTA OIDC APPLICATION

This will allow your users to login to Hava via a custom Okta OIDC application. These steps can be followed for most SSO identity providers, though the field names may be different. Custom apps will be coming soon.

1. Log into Hava and head to your Account Settings. From there select SSO Config, then click OIDC on the protocol selection page. This will show you the Service Provider values you will need to enter into Okta

2. Log into Okta and click Applications → Create App Integration

3. Select ‘OIDC - OpenID Connect’ and then ‘Web Application’ for the Application type, then click Next

4. Enter the following details into the settings:

   1. Name should be Hava

   2. Grant Type should be Authorization Code

   3. Sign-in redirect URIs should be set to the value of Sign-in Redirect URI from the Service Provider section in Hava

   4. Assignments should be set based on your requirements

5. All other values can be left as the defaults. Click Save to complete the Okta setup.

6. Head back to the Hava SSO OIDC config page and select Add OIDC Config

7. Enter the config values from the Okta setup instructions:

   1. Identity Provider Host should be set to Okta domain without any prefix or trailing slash, i.e. http://test-oidc.okta.com and not http://test-oidc.okta.com/

   2. OIDC client ID should be set to Client ID

   3. OIDC client Secret should be set to Client secret

Click Save to complete the setup

ENABLING THE SSO PROVIDER

Once you’ve configured your provider your team members will still be able to login to your account with their standard user and password, as well as the SSO provider. This allows you to test and update the details, or remove them if they are no longer required.

Once you have defined your configuration you can enable your provider - this will prevent users accessing your account unless they are logged in via your SSO provider.

Once a provider is enabled all users will need to login through your IDP to access your account, except for the account owner. If you need to modify or delete your configuration you will first need to disable the provider.

DISABLING AND DELETING SSO

If you no longer require a configured SSO provider, or you’d like to move to a new one, you can delete your existing configuration. Your provider must be disabled for the delete option to appear.

Once your SSO provider is removed your team members will once again be able to access your account through password login.

Hava SSO FAQ

SSO is currently only available on Business plans and is currently in beta. Contact us at support@hava.io if you would like to try it out.

So that's a quick run through of SSO and Hava's SSO capabilities. If you have any questions, please get in touch.

 

If you are not using Hava to automatically generate your AWS, Azure or GCP cloud network topology diagrams, then please click the button below and take a free trial.