Whether it is an internal app for employees, or a portal for business partners or customers, user identification and authorized access is important. The right authentication and authorization support enables organizations to minimize security risks and improve user experiences.

Typical business applications use credentials (or passwords) to authenticate users and grant access to the permitted resources. Majority of businesses operate online nowadays, having several platforms each with its own login page. As the number of these applications increases, so do password-related risks, breaches, and theft. To protect users against them, several methods and technologies are available to authenticate and authorize the right user.

One such technology is Single Sign-On. It is an authentication method that offers seamless access to multiple services requiring passwords while having to sign on only once, thus reducing the attack surface. It has been a popular authentication system among users, developers, and IT Admins for easy installation, streamlined password management, and security.

In this blog, we’ll see how Single Sign-On works and can be configured in Wyn Enterprise, covering the following topics:

• Fundamentals of Single Sign-on

  • Types of SSO approaches

  • Authentication v/s Authorization
    
    

• Single Sign-On in Wyn Enterprise

  • Configure SSO in Wyn Enterprise

Fundamentals of Single Sign-On

Single Sign-On (SSO) is a mechanism that allows users to access multiple, password-based services or applications while having to sign on once. In this system, a user access application(s) bypassing the application’s login page as they are already authenticated with the SSO system.

A typical SSO system consists of an Identity provider and a Service Provider (or Business application). An identity provider (IdP) is a service that stores and works with the Service provider to verify the user’s identity. There are several Identity providers available such as LDAP, ActiveDirectory, OneLogin, Okta, Microsoft Azure AD, Amazon Cognito, Google Cloud Service, and many others. To communicate with the Service Provider, the Identity providers use open protocols such as OAuth, SAML, OpenID Connect, and others.

SSO integration in an Enterprise system or a SaaS application makes them secure and decreases the attack surface. It saves user setup time for the IT team, cost of user integration and password resets, improves user experience, and increases productivity specifically when working remotely. In a general SSO system, the sequence of requests between an Identity and Service provider is as described in the illustration below:

Once a user is authenticated, he can access the same or different application (with SSO configured) using the same token from an active SSO session. Thus, saving efforts to enter login credentials again for user authentication.

Types of SSO approaches

Depending on where the sign-on request is generated, the Single sign-on mechanism is categorized into two types, namely, IdP-initiated SSO and SP-initiated SSO.

In an IdP-initiated SSO, the user logs into the IdP application containing all the internal and external applications for which the admin has configured SSO. The user clicks on the visual icon for the application and is logged in without prompting for credentials.

With an SP-initiated SSO, the user logs into the business application for which the admin has configured SSO. The login request initiated by the application is redirected to the IdP access page for authentication. The identified and authenticated user then access the application by bypassing its login page.

Authentication v/s Authorization

Authenticating and Authorizing users are an important part of an SSO system. Although they may sound similar, but they have a subtle difference. Authentication checks and ensures the validity of the user for a system or service provider. It validates that users are who they claim to be. Authorization on other hand is a process of giving the user permission to access a specific resource or function.

Most of the SSO Providers authenticate users to access web applications and do not serve to authorize users. Administrators determine and set up, within the business application, users who have authorization access and privileges to system resources.

Single Sign-On in Wyn Enterprise

Wyn Enterprise supports SP-initiated SSO (or application-initiated SSO) for user authentication. You can integrate popular identity providers such as Okta, Microsoft Azure AD, CAS, Google Cloud Service, Amazon Cognito Service, using the respective authentication protocols - OAuth2, OpenID Connect, and CAS.

Once the desired SSO provider is configured with Wyn Enterprise, the user is redirected to the Identity provider for authentication whenever he accesses the Wyn Portal. The user provides his credentials on the IdP login page and upon valid identification granted access to Wyn Portal. However, the resources he is authorized to access are defined by the Wyn Server. The detailed SSO process in Wyn Enterprise is depicted using the flow diagram below:

This whole security architecture ensures easy access to Wyn resources while maintaining data integrity and controlled data governance regulations.

Let’s see how we can configure SSO in Wyn Enterprise.

Configuring SSO in Wyn Enterprise

Integrating SSO with Wyn Enterprise involves simple steps and settings. As a pre-requisite, you should have installed Wyn Enterprise higher than version 6.0 and should have configured the authentication provider by adding users. Then locate and open for edit the Wyn Enterprise configuration file (Wyn.conf) situated at <installation directory>\Wyn Enterprise\Monitor\conf. Modify the file by adding to the <Server> node a <Authentication> node containing the <SSO> node with the required SSO configurations. A sample is attached below:

<Server>
...
  <Authentication>
    <SSO>
      <AuthenticationProtocol>{authentication protocol}</AuthenticationProtocol>
      <Scheme>{identity provider}</Scheme>
      <Disabled>true|false</Disabled>      
      <Authority>{authority_url}</Authority>
      <ClientId>{your_client_id}</ClientId>
      <ClientSecret>{your_client_secret}</ClientSecret>
      <ResponseCode>{your_code}</ResponseCode>
      <Callback>{your_IdP_callbackURL}</Callback>
      <Scopes>
        <sys:string>{authentication_provider_scopes}</sys:string>
        ...
      </Scopes>      
    </SSO>
  </Authentication>
</Server>

For more details about each of these elements (or nodes) in the config file, follow the user guide.

Once the configuration is done, save the file and restart the server to enable SSO in Wyn Enterprise.

Apart from these commonly used authentication settings, Wyn Enterprise supports several other settings for better security and management against unauthenticated access. They include,

• Incognizant mode
• Claim management
• Single Logout (SLO)
• Cookie management

Let’s see what these are and how to configure them in Wyn Enterprise.

Incognizant Mode

Often the external authentication server stores users' information for federated applications. Thus, not all users are expected to access all sites (or applications). You want to bypass and allow only a few users in the external authentication server to log in, that is, disable the incognizant access to an application resource.

Wyn Enterprise supports to control incognizant access with selected providers. When you want to discourage incognizant access to Wyn Enterprise, the users should be imported to Wyn before setting up an SSO configuration. All the users in the external authentication server can perform the SSO process when accessing Wyn Enterprise but, only the users that are already imported to Wyn Server can log in successfully. Other users are redirected to the access denied page from the authentication provider as described in the flow diagram below:

User Claim (or Contextual information)

Within the SSO system, the authenticated user is represented by claims. After the SSO process is finished successfully, you can get the information about the authenticated user such as name, phone number, email, avatar, roles, etc. The contextual information retrieved is absolutely controlled by the authentication server. It is used while creating a user in Wyn Enterprise when he logs in for the first time on the Wyn Portals.

The user contextual attributes from the authentication provider are mapped to the user context in Wyn using the <ClaimMappings> settings under the <SSO> node in Wyn.conf file. A ClaimMapping item consists of a key and a value, where the former represents the user context in Wyn and the latter represents the user context from the authentication provider. For more details, follow the documentation.

Single Logout (SLO)

Wyn Enterprise also supports SLO (single logout) with selected providers - CAS and Microsoft Azure AD. With SLO, the user logs out of the identity server and the business application with a single action.

To enable SLO, set to true the <EnableSLO> setting within the <SSO> node in the configuration file. For more details, check out the documentation.

Cookies Management

In applications, cookies are a way used to identify and retain user preferences. The browser stores and returns the cookie to the server whenever a page is requested. Wyn Enterprise offers to handle and manage HTTP cookies settings (or attributes) such as secure, same site, domain, path, etc. Cookies such as HTTP cookies can be used to perform user authentication, maintain a session for the user, enter the application, and access secured pages without asking for credentials again. Learn how to add cookies settings in Wyn Enterprise. Cookies are especially required when working with external SSO provider to allow communication across domains.

The above-described authentication settings are common to all the identity providers supported in Wyn Enterprise. However, the values vary for the nature and the type of supported protocol. For the purpose of this blog, we configured Wyn Server for SSO integration with MS Azure AD and the config file looks like the below:

<Server>
...
  <Authentication>
    <SSO>
      <AuthenticationProtocol>OIDC</AuthenticationProtocol>
      <Scheme>Microsoft_ADD</Scheme>
      <Disabled>false</Disabled>      
      <Authority>https://sts.windows.net/{your_directory(tenant)_id}</Authority>
      <ClientId>4e23ogrt-xxx-xxx-xxx-xxx-ef423s5t</ClientId>
      <ClientSecret>12s34d00-xxx-xxx-xxx-wsd23f5t</ClientSecret>
      <ResponseCode></ResponseCode>
      <Callback></Callback>
      <Scopes>
        <sys:string>customscope1</sys:string>
        <sys:string>customscope2</sys:string>
      </Scopes>   
      <EnableSLO>true</EnableSLO>   
      <AllowIncognizantUser>true</AllowIncognizantUser>
      <ClaimMappings>
          <sys:Item>
            <Key>sub</Key>
            <Value>sub</Value>
          </sys:Item>
          <sys:Item>
            <Key>name</Key>
            <Value>nickname</Value>
          </sys:Item>
          <sys:Item>
            <Key>given_name</Key>
            <Value>given_name</Value>
          </sys:Item>
          <sys:Item>
            <Key>family_name</Key>
            <Value>family_name</Value>
          </sys:Item>
          <sys:Item>
            <Key>email</Key>
            <Value>email</Value>
          </sys:Item>
      </ClaimMappings>      
    </SSO>
  </Authentication>
  <Cookie>
    <ShareCookie>false</ShareCookie>
    <SameSite>None</SameSite>
    <Secure>true</Secure>
  </Cookie>
</Server>

For configuration settings related to other authentication providers, check out the documentation.

Conclusion

Integrate and build a secure, protected, and one-login system using SSO in Wyn Enterprise. In the upcoming releases, to ease the configuration and setup process, these settings will be available on Wyn Admin Portal. So, stay tuned.