Tag Archive: saml

Two ways to integrate/federate applications with Azure AD:

Azure marketplace:


check if the application exists:

The Microsoft Azure Marketplace is an online store that offers applications and services either built on or designed to integrate with Microsoft’s Azure public cloud.

Else, how to configure single sign-on to applications that are not in the Azure Active Directory application gallery: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps

Authentication scenarios for Azure AD:


Applications integrated with Azure: the access via https://account.activedirectory.windowsazure.com/applications/default.aspx

Integrating applications with Azure AD: https://docs.microsoft.com/fr-fr/azure/active-directory/develop/active-directory-integrating-applications


Identity hybrid ports and protocols:



Azure app gallery:


If not pre-packaged in Azure marketplace: Any app that supports SAML 2.0 can be integrated directly with an Azure AD tenant using these instructions to add a custom application.

Provide credentials for a test tenant or account with your application that can be used by the Azure AD team to test the integration.

Provide the SAML Sign-On URL, Issuer URL (entity ID), and Reply URL (assertion consumer service) values for your application, as described here. If you typically provide these values as part of a SAML metadata file, then please send that as well.

Provide a brief description of how to configure Azure AD as an identity provider in your application using SAML 2.0. If your application supports configuring Azure AD as an identity provider through a self-service administrative portal, then please ensure the credentials provided above include the ability to set this up.

Configuring single sign-on to applications that are not in the Azure Active Directory application gallery:



Sign On URL (SP-initiated only) – Where the user goes to sign-in to this application. If the application is configured to perform service provider-initiated single sign on, then when a user navigates to this URL, the service provider will do the necessary redirection to Azure AD to authenticate and log on the user in. If this field is populated, then Azure AD will use this URL to launch the application from Office 365 and the Azure AD Access Panel. If this field is ommited, then Azure AD will instead perform identity provider -initiated sign on when the app is launched from Office 365, the Azure AD Access Panel, or from the Azure AD single sign-on URL (copiable from the Dashboard tab).

Issuer URL – The issuer URL should uniquely identify the application for which single sign on is being configured. This is the value that Azure AD sends back to application as the Audience parameter of the SAML token, and the application is expected to validate it. This value also appears as the Entity ID in any SAML metadata provided by the application. Check the application’s SAML documentation for details on what it’s Entity ID or Audience value is. Below is an example of how the Audience URL appears in the SAML token returned to the application

Reply URL – The reply URL is where the application expects to receive the SAML token. This is also referred to as the Assertion Consumer Service (ACS) URL.






If you’re doing research on protocols that enable single sign-on, a typical question is, “How does SAML work?” (credits: http://www.gluu.org/blog/how-does-saml-work-idps-sps/)

” SAML, or Security Assertion Markup Language, is the leading SSO protocol today and is a valuable standard to understand in order to fully comprehend how single sign-on works.

SAML boils down to attribute exchange through the creation of trust relationships between IdP’s and SP’s. A basic example is signing into your active directory to log on to your work computer in the morning, and automatically gaining access to your company gmail or salesforce.

The three main components of the SAML protocol:

  • Assertions – Most common are the following 2 SAML assertions:
    • Authentication assertions are used to make people prove their identities.
    • Attribute assertions are used to generate specific information about the person, for example their phone number or email address.
  • Protocol – This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP.
  • Binding – This details exactly how SAML message exchanges are mapped into SOAP exchanges.

5 Benefits of using a SAML IdP:

There are many reasons to use a SAML IdP. Besides being the dominant single sign on protocol in use today, there are a host of reasons an organization should consider implementing a SAML IdP. Here are 5 reasons to use SAML for SSO:

1. User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple Web application passwords are no longer required.

2. Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class IdM first, which can include strong authentication mechanisms.

3. “SP-initiated” SAML SSO provides access to Web apps for users outside of the firewall. If an outside user requests access to a Web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall.

4. Centralized federation provides a single point of Web application access, control and auditing, which has security, risk and compliance benefits.

5. A properly executed identity federation layer that satisfies all of the use cases described above and supports multiple protocols can provide an enterprise-wide, architecturally sound Internet SSO solution ”

For more on the SAML protocol and transaction steps, go to: http://en.wikipedia.org/wiki/SAML_2.0

SAML transaction steps (overview): Let’s take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:

In Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.

In Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.

In Step 3 the SAML service appends a partner ID and a special handle to Site 2’s URL in the user’s browser. For example, if the user wants to go to the site http://www.softprovider.com, after the SAML service appends the extra information, the URL might now be https://www.softprovider.com?SAMLart=  . Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2’s SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2’s SAML service communicates with Site 1’s, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.

In Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.


When Kerberos was chosen to be AD’s authentication protocol in the mid- to late-1990s, the World Wide Web was a shadow of what the Internet offers today. Although the Kerberos ticket contained an encrypted password hash that could be attacked, there wasn’t any substantial requirement to provide support outside the highly protected corporate firewall.

The rise of cloud services is changing many aspects of our lives, and these services don’t support external authentication via Kerberos because of that password vulnerability. If a web service uses standards, it handles claims-based authentication using SAML 2.0 or, increasingly, OAuth 2.0 and OpenID Connect. Microsoft’s own Azure Active Directory doesn’t use Kerberos; it supports SAML and OAuth 2.0 as its authentication protocols.




Wikipedia Article: OAuth



OAuth in details

OAuth is an authorization method to provide access to resources over the HTTP protocol.


OAuth2 can be used for authorization of various apps (server/browser/mobile)and desktop applications or manual user access.

The general way it works is allowing an application to have an access token (which represents a user’s permission for the client to access their data) which it can use to authenticate a request to an API endpoint.

Oauth 2 flow

A sample OAuth flow: Facebook

OAuth versions

There are two versions of OAuth authorization OAuth 1 (using HMAC-SHA signature strings) and OAuth 2 (using tokens over HTTPS).

Note: SoapUI currently only offers Oauth2 authorization.

OAuth 2 terms

Conceptually, OAuth2 haas a few components interacting: The resource server (the API server) contains the resources to be accessed. Access tokens are provided by the authorization server (which can be the same as the API server). The tokens are provided by the resource owner (the user) when accessing the resources. Similarly, an application using the credentials, and the API is called client.

End Points

The token Endpoint is used by clients to get an access token (and optionally refresh token) from the authorization server.

Note: When using implicit grant, this endpoint is not used. Instead the access token is sent from the authorization endpoint directly.


The two token types involved in OAuth 2 authentication are Access Token and Refresh Token.

Access Token

The access token is used to for authentication and authorization to get access to the resources from the resource server.

Refresh Token

The refresh token normally is sent together with the access token.

The refresh token is used to get a new access token, when the old one expires. Instead of the normal grant type, the client provides the refresh token, and receives a new access token.

Using refresh tokens allows for having a short expiration time for access token to the resource server, and a long expiration time for access to the authorization server.

Token Types

Access tokens have a type, which defines how they are constructed.

Bearer Tokens

The bearer tokens use HTTPS security, and the request is not signed or encrypted. Possession of the bearer token is considered authentication.

MAC Tokens

More secure than bearer tokens, MAC tokens are similar to signatures, in that they provide a way to have (partial) cryptographic verification of the request.


Methods to get access tokens from the authorization server are called grants. The same method used to request a token is also used by the resource server to validate a token.

The four basic grant types are Authorization Code, Implicit, Resource Owner Credentials and Client Credentials.

Note: SoapUI currently only offers the grant types Code Grant and Implicit.

Authorization Code

With authorization_code grant, the resource owner allows access. An authorization code is then sent to the client via browser redirect, and the authorization code is used in the background to get an access token. Optionally, a refresh token is also sent.


The implicit grant is similar to authorization code, but instead of using the code as an intermediary, the access token is sent directly through a browser redirect.

Not yet in SoapUI Resource Owner Credentials

The password/Resource Owner Credentials grant takes the uses the resource owner password to obtain the access token. Optionally, a refresh token is also sent. The password is then discarded.

Not yet in SoapUI Client Credentials

In client_credentials grant mode, the client’s credentials are used instead of the resource owner’s. The access token is associated either with the client itself, or delegated authorization from a resource owner.

Grant Type Extensions

OAuth has a mechanism for extending grant types as a bridge to other authorization frameworks, or for specialized clients.

Extension grants are used by clients through an absolute URI together with a grant_type parameter and by adding any additional parameters necessary to the end point.


In OAuth 2, the scope is a way to restrict access to specified areas. A common way of handling it is with a comma-separated or space-delimited list of strings, where each string indicates an areas of access.





Web articles:



Web sites to decode base64 SAMLResponse:



URL decoder tool: http://meyerweb.com/eric/tools/dencoder/
BASE 64 decoder tool: http://www.opinionatedgeek.com/dotnet/tools/base64decode/

Understanding SAML: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

Cisco Webex, SSO troubleshooting: http://www.cisco.com/c/en/us/td/docs/collaboration/CWMS/1_1/b_troubleshootingGuide/b_troubleshootingGuide_chapter_01001.html