Testing SSO Solutions That Use SAML 2.0 and OAuth 2.0 in Windows Active Directory

More and more organizations are facing a situation when some applications are located on the corporate network (Active Directory, mail servers, etc.), while others (SaaS solutions) are located in private or public clouds. These organizations feel an urgent need to make their authentication and authorization processes both safe and easy. This challenge can be solved with single sign-on technology that authenticates a user without providing credentials to each resource.

In this article, we explain how you can start testing SSO applications at the earliest stages of development based on the two most popular communication standards: Security Assertion Markup Language (SAML) 2.0 and OAuth 2.0.

This article will be useful for quality assurance specialists and developers who are testing single sign-on solutions.

Single sign-on technology

So what is single sign-on? Single sign-on (SSO) technology is now very popular due to its ability to enhance security and simplify administration of users and their access rights to various applications. With SSO, a user can log in at one place – a local PC, a web portal, a native application – and get access to various network resources without having to enter a password for each.

There are various benefits of SSO:

• SSO improves security of corporate resources, as user passwords aren’t sent between applications.
• SSO simplifies user administration, as access to new resources is provided at the configuration stage.
• With SSO, users no longer need to remember passwords to countless applications.
• SSO reduces the risk of phishing and other attempts at compromising a user’s credentials.

Organizations often use hybrid environments, where some enterprise applications are located on-premises while others run in the cloud. At this point, ensuring seamless integration becomes a real issue. One possible solution is to use SSO technology, where an outside identity provider serves as an authentication server.

Many SaaS providers allow for authenticating local Active Directory users by integrating a customer’s on-premises domain with the cloud domain. Active Directory (AD) is a Microsoft directory service that authenticates and authorizes all users in a Windows domain network through a domain controller, also known as an authentication server. Microsoft is also an SSO provider, offering Azure Active Directory as a reliable and scalable cloud service for identity and access management.

In order to understand how single sign-on works, let’s look at the following diagram, which illustrates the process of local user authentication and authorization in a Microsoft Azure cloud application:

 

Image source: Microsoft Azure Active Directory

Analyzing the above diagram, you may notice that any SSO solution for Windows should meet the following requirements:

•  A client’s device should be a member of Windows AD.
• The local and cloud AD instances should be synchronized.
• The target application should support Kerberos authentication.

Let’s talk about how to meet all these requirements and start SSO testing even before all application functionality is implemented.

How to meet all SSO requirements for Windows

It’s great when our SSO solution covers all the requirements for authentication and authorization through Windows AD. But what if some of these conditions for single sign-on authentication can’t be met? For example, what if the client device isn’t a member of AD and/or it doesn’t support the Kerberos protocol?

Currently, there are many protocols that support a single sign-on service in addition to Kerberos. In our projects, we prefer to use OAuth 2.0 and SAML 2.0.

These two authentication and authorization protocols allow for significantly expanding single sign-on implementations.

In particular, using either of these two protocols allows an SSO solution to provide access to terminal servers (like Remote Desktop Session Host for Windows domain users) and authenticate them through third-party cloud services like Okta, Azure, AWS, and OneLogin.

How do SAML 2.0 and OAuth 2.0 work in AD?

To begin, let’s explain the key terminology of SAML 2.0 and OAuth 2.0. These two tools use different terminology, but they’re conceptually the same.

Authentication and authorization with SAML 2.0 and OAuth 2.0

When using SAML 2.0 or OAuth 2.0 as an SSO protocol in Microsoft AD, the service provider (SP) acts as a trusted intermediary between the identity provider (IdP) and Microsoft Active Directory. Here’s how it works:

1. The client is authenticated by the IdP or AS.
2. The IdP issues SAML assertion for SAML 2.0, while the AS issues an access token for OAuth 2.0 (simply referred to as a token).
3. The client sends the assertion/token to the SP/RS.
4. The SP/RS validates the assertion with the IdP/AS.
5. The SP/RS decrypts and validates user information received from the assertion and AD.
6. The SP/RS provides the client with access to resources.

This solution has the following advantages:

• Integration into existing infrastructure doesn’t require significant changes to that infrastructure.
• You can use multiple identity providers in the same infrastructure.
• You can use multiple AD forests with one identity provider.
• Changing or adding an identity provider is seamless for users.
• The openness of the protocols used simplifies a security audit.

It’s best to begin testing SSO solutions based on SAML 2.0 and OAuth 2.0 as early as possible in order to reduce possible defects and costs of fixing them. For instance, you can create state transition diagrams when you are still developing specifications. This allows you to test whether the functionality of your application based on SAML 2.0 or OAuth 2.0 accounts for all possible steps a user may take during the authentication process. This approach allows you to discover business logic flaws in your application and fix them with minimum effort and cost.

Now, we’ll talk about preparing the infrastructure for testing SAML and OAuth-based SSO solutions.

Testing SAML-based solutions

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between an identity provider, service provider, and client.

Here’s a scheme for user authentication based on SAML 2.0:

Azure, Okta, OneLogin, or any other similar service can be used as an IdP.

For testing purposes, we use Okta as an IdP and simpleSAMLphp as an SP. We also use Fiddler for monitoring the user authentication process.

These tools allow you to start functional testing of your SSO solution even before all of your product functionality is developed. They also help you save the time of developers and reduce overall costs of application development by eliminating the need to develop special tools for SSO testing.  

Benefits of using these SSO testing tools:

• Free to use
• Well-structured documentation and huge communities
• Infrastructure is easy to adjust to your SSO solution
• You can combine these tools, as they’re independent of each other

Drawbacks of using these SSO testing tools:

• Security risks, as user verification is done on the testing tool resources

Here’s what we need to do to make our SP work with the chosen IdP:

1. Develop an application that supports SAML authentication (more details on this process here).
2. Configure the local simpleSAMLphp application for authentication in your SSO application by making changes to metadatasaml20-idp-remote.php

<?php
$metadata['OKTA'] = array (
  'entityid' => '[App Embed Link]',
  'contacts' =>
  array (
  ),
  'metadata-set' => 'saml20-idp-remote',
  'SingleSignOnService' =>
  array (
      0 =>
      array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      'Location' => “ Okta app address”/sso/saml',
      ),
      1 =>
      array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
      'Location' => Okta app address”/sso/saml'',
      ),
  ),
  'SingleLogoutService' =>
  array (
      0 =>
      array (
      'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
      'Location' => ',
      ),
  ),
  'ArtifactResolutionService' =>
  array (
  ),
  'keys' =>
  array (
      0 =>
      array (
      'encryption' => false,
      'signing' => true,
      'type' => 'X509Certificate',
      'X509Certificate' => ‘Base64 string',
      ),
  ),
);

SimpleSAMLphp and the Okta IdP allow us to emulate the whole process of authenticating the user and receiving SAML assertion (a data package with information on the user and their signature).

Let’s see how the configured test environment works step by step:

1. Run simpleSAMLphp:
2. Go to the Authentication tab, select Test configured authentication sources, find Default-sp, and select your IdP.
3. Then you’ll be redirected to the Authentication tab of the chosen IdP.

After successful authentication in the IdP, the SAML-based SSO application runs. Now, you can use Fiddler to intercept the SAML assertion where all the necessary data is stored.

<?xml version="1.0" encoding="UTF-8"?><saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http:// <app address>" ID="id1553079307929379" InResponseTo="_e3e3d0b0482d8b9a23986f3908adc88" IssueInstant="2019-03-01T09:59:40.492Z" Version="2.0"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exkffkgx09CD7J0h7</saml2:Issuer><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></saml2p:Status><saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="id1516330313532025589711" IssueInstant="2019-03-01T09:59:40.492Z" Version="2.0"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">http://www.okta.com/exkffkgx09D7J0h7</saml2:Issuer><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"><span id="cloakb10e955377851d0b88ce0eb568c83c27"><a href="mailto:[email protected]">[email protected]</a></span><script type="text/javascript">
        document.getElementById('cloakb10e955377851d0b88ce0eb568c83c27').innerHTML = '';
        var prefix = 'ma' + 'il' + 'to';
        var path = 'hr' + 'ef' + '=';
        var addyb10e955377851d0b88ce0eb568c83c27 = 'userpan' + '@';
        addyb10e955377851d0b88ce0eb568c83c27 = addyb10e955377851d0b88ce0eb568c83c27 + 'ericomdemo' + '.' + 'info';
        var addy_textb10e955377851d0b88ce0eb568c83c27 = 'userpan' + '@' + 'ericomdemo' + '.' + 'info';document.getElementById('cloakb10e955377851d0b88ce0eb568c83c27').innerHTML += '<a ' + path + '\'' + prefix + ':' + addyb10e955377851d0b88ce0eb568c83c27 + '\'>'+addy_textb10e955377851d0b88ce0eb568c83c27+'<\/a>';
    </script></saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData InResponseTo="_e3e3d0b0482d9c69acd691908adc88" NotOnOrAfter="2019-03-01T10:04:40.492Z" Recipient="https://app"/></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2019-03-01T09:54:40.492Z" NotOnOrAfter="2019-03-01T10:04:40.492Z"><saml2:AudienceRestriction><saml2:Audience>< our app></saml2:Audience></saml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2019-03-01T09:59:40.007Z" SessionIndex="_e3e3d0b0986f309c69acd691908adc88"><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">User</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Pan</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">username@username</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string"> username@username</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion></saml2p:Response>

You can change the information stored in the SAML assertion and add required user attributes. All these changes can be made in the settings of your SAML-based application on the IdP side.

Testing OAuth-based applications

OAuth 2.0 is an open standard for authentication and authorization that provides access to resources without giving them a login and password. Authorization is performed through tokens that are issued and confirmed with the authorization server.

Here’s a high-level model of OAuth 2.0 authentication:

Although the main purpose of OAuth 2.0 is to provide access to resources, it can also be used to provide SSO services, just like SAML.

Various cloud services – such as Azure, Okta, OneLogin, and AWS – can act as the authorization server. Therefore, when developing and testing solutions based on SAML or OAuth authorization, you can use a single infrastructure. And using a single infrastructure will allow you to spend less time on test environment preparation and continued support.

In our case, we used Postman to receive the access token for OAuth 2.0 authentication.

Postman is a convenient tool that provides an API development environment for automated testing. It has lots of built-in tools and is free for small teams.   

The process of developing an application that supports OAuth 2.0 authentication and authorization is described here.

To receive the OAuth 2.0 access token, your SSO application should send a POST request with the following information:

• The address for sending the request: https://login.microsoftonline.com/<Tenant ID>/oauth2/token
• The request:

client_id:f07aee38-bdfd-4747-9f3f-0000000000
grant_type:password
resource:f07aee38-bdfd-4747-9f3f-0000000000
client_secret:juEqLuaDLPueqa+ /BYU=
username:<span id="cloake988aa03aaec0e9b6f515cf9eb82110f"><a href="mailto:[email protected]">user@domain.com</a></span><script type="text/javascript">
        document.getElementById('cloake988aa03aaec0e9b6f515cf9eb82110f').innerHTML = '';
        var prefix = 'ma' + 'il' + 'to';
        var path = 'hr' + 'ef' + '=';
        var addye988aa03aaec0e9b6f515cf9eb82110f = 'user' + '@';
        addye988aa03aaec0e9b6f515cf9eb82110f = addye988aa03aaec0e9b6f515cf9eb82110f + 'domain' + '.' + 'com';
        var addy_texte988aa03aaec0e9b6f515cf9eb82110f = 'user' + '@' + 'domain' + '.' + 'com';document.getElementById('cloake988aa03aaec0e9b6f515cf9eb82110f').innerHTML += '<a ' + path + '\'' + prefix + ':' + addye988aa03aaec0e9b6f515cf9eb82110f + '\'>'+addy_texte988aa03aaec0e9b6f515cf9eb82110f+'<\/a>';
    </script>
password:user’s password

Where:

• Tenant ID is your Azure AD ID
• client_id and resource are the unique application ID of the application in your Active Directory
• Client_secret is a one-time key received when configuring the application key

After sending a request with valid data, we get the following reply:

{
          "token_type": "Bearer",
          "scope": "User.Read",
          "expires_in": "3600",
          "ext_expires_in": "3600",
          "expires_on": "1551694226",
          "not_before": "1551690326",
    "resource": "f07aee38-klhu-4747-9f3f-8b3ea3f9d073",
          "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ii1zeE1KTUxDSURXTVRQdlp5SjZ0eC1DRHh3MCIsImtpZCI6Ii1zeE1KTUxDSURXTVRQdlp5SjZ0eC1DRHh3MCJ9.eyJhdWQiOiJmMDdhZWUzOC1iZGZkLTQ3NDctOWYzZi04YjNlYTNmOWQwNzMiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83YTU3NmI1Yi00MDk5LTQzYzMtOWQzMi0xYzgzYmVjYjBlYzgvIiwiaWF0IjoxNTUxNjkwMzI2LCJuYmYiOjE1NTE2OTAzMjYsImV4cCI6MTU1MTY5NDIyNiwiYWNyIjoiMSIsImFpbyI6IkFTUUEyLzhLQUFBQXkyOEYzNVN1OENacHdkb0U3aTFSa0psTzdHWW5QOGZxVElUMVpFVFcwTWM9IiwiYW1yIjpbInB3ZCJdLCJhcHBpZCI6ImYwN2FlZTM4LWJkZmQtNDc0Ny05ZjNmLThiM2VhM2Y5ZDA3MyIsImFwcGlkYWNyIjoiMSIsImdpdmVuX25hbWUiOiJ1c2VyIiwiaXBhZGRyIjoiOTEuMTkzLjEyOS4xODIiLCJuYW1lIjoidXNlciIsIm9pZCI6IjVlMzliYjUyLTc2NTAtNDVhZi1hOTM2LWIxOTM4OWY0M2YzOSIsIm9ucHJlbV9zaWQiOiJTLTEtNS0yMS0xNjg3MTg4OTg5LTU1NjAzODExNC0xNzAzODUzMTIxLTExMTAiLCJzY3AiOiJVc2VyLlJlYWQiLCJzdWIiOiJpcnJhOWRxUG5NM1UycmVlYmxwaXg4cHJtWkxNeVN3S3lhM19ka2ttaWRjIiwidGlkIjoiN2E1NzZiNWItNDA5OS00M2MzLTlkMzItMWM4M2JlY2IwZWM4IiwidW5pcXVlX25hbWUiOiJ1c2VyQGtvc3RlbmtvYW50b25hJvc29mdC5jb20iLCJ1cG4iOiJ1c2VyQGtvc3RlbmtvYW50b25hcHJpb3JpdC5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJ2QY0xCY3pFaVk3dGFPeFNRN0FBIiwidmVyIjoiMS4wIn0.bL72Bc8vYJjtzPX3r2iBNJlUCO-VvQTt5I6Azq8oFpf3LoafT4rMSkWXHqt9eF9dJUQrr8ibk6DIGQXnsabiix1r9A-9e-bvA9VOqWLQJqyHqZYgJ1n-f5RmZdSg8nhuVoKU8zmwnxDFqv9h6025iXCYF0utLmOkMN1JkrlNB4fEChdNXQPf0AIp1_ISBB2Jf6-jkaGSqE0yB0SDTYYaecdw_y7P8WlDB_R1zp4FcqndG67RC3QvzYYoC1ImlWxywaIQYfUGIMKYsme1_s9LAEcJGejRHSMrHobHGvbeN0MeoMqx3zvtHb1BKrY2AqAerN16fBpizFI_2AURnoytRA",
          "refresh_token": "AQABAAAAAACEfexXxjamQb3OeGQ4GugvFDXBcVJcMePZieE-QlEHPWoJEE6zXMDAGYNBWUxtu0BwDY32YJUs1Jmq-vWWK8ariNpRwE9jaIPr5O8_LZEViLuxgLtXPTCFz2V8GLhbKT3ZcGCsb2xDLEkH4i8FnONIQZNX-ycIvhwh0SX_KJkdryP0WddNjCUtTyr1Tz50uwirshoZoGISYph0z9oFi7UH9iP4kLE1Af_NQkBHoRnGoZvIHuLdRakHGBPDIpJXGv8BGvVYwznLtxAELq1Wq364uJucG_GYLXGyxxetoO8Pb7CYd8-znoR7KeggDPEPuDImvOPYAqrfxFvIiBVnKutzgW3sVbit2KdnwbsZJEKKBO9mzmmAm9Zf0W1UFw1CqIlmpPX-8HeP_ca0c2r4ISlqURR22MI_YO3pylNGnOSEmTuHLd3x5ZKsbwDeBCzTi3aBOvHKKuA9Gzw7Zz27McaKIwXQ9MrtQwptgkOAlykXYlVodVHY3hLfalOiDrgKxNigF1DBQzxuWSPdRrpHAh5mVG6IqfBIzwmFehQQhBWCiotx77LNlqE9Fj_OiYY5NiZwTfV_NhqUPBClk1yLTufMbsos-FkKKIAD8_WwVa6blIXr_TpRE28jH9vDxUpLXmbDSDjWuDov_CnNiKYBjjQLd5e-NVYNkC6ZC2H6FcAUNy8vS7-FLHzSv8fr8UbFUjEAGlKrP-kSkvMU2AFixZWS71oY0OYdaT7Aj-iAA"
}

The access token includes all the information needed for user authentication.

Conclusion

It’s important to test SSO solutions at the earliest stages of development, when application functionality is still only partially implemented and many operations must be performed manually. This way, you’re more likely to find any defects early and, as a result, significantly reduce the cost of fixing them.

Apriorit has a team of qualified quality assurance specialists who will be glad to assist you in testing your software solutions. Feel free to contact us via online chat or by filling out the form below.