INTEGRATING SERVICENOW WITH OKTA FOR SINGLE SIGN ON (SSO)

Today’s blog features a tutorial detailing everything you need to know in order to provision users from Okta to ServiceNow and Federated ServiceNow Application using SAML 2.0 (Security Assertion Markup Language).

Okta is a cloud-based identity management product that helps companies manage and secure user authentication and build identity controls into applications.Through this blog, we will show user provisioning from Okta to ServiceNow and configuration of Single Sign-On using Identity Provider and Service Provider Initiated Mechanism through SAML.

Prerequisites:

• Administrative ServiceNow Account
• Application Administrative Okta Account

Configuration Steps at Okta:

1. Login to your OKTA console & click on Applications --> Add Application Button. 
2. Search for serviceNow UD as shown below. 

1. Click on the ADD Button on the Left Pane. Provide the Application URL of your ServiceNow Instance under the Base URL field. In this demo, we have used a dev instance as shown below.
2. Under the Provisioning tab, Enable API Credentials using ServiceNow admin account as shown below. 

1. After successful API Integration, we can create, update and deactivate users from Okta to ServiceNow by defining the Provisioning Rule as shown below. 

    5. Under the Assignments Tab, assign the application to a user or a group. In this demo we have assigned the application to a user for testing as shown below. 

    6. Under the Sign On Tab, download the Identity Provider Metadata as shown below. 

    Save the above IDP URL. 

Configuration Steps to be Done at ServiceNow:

1. Log in to ServiceNow as the administrator as shown below. 

   2. Search for plugins in the Filter navigator (left pane window) & Click on Plugins. 

   3. Search for com.snc.integration.sso.multi in the ID field from the search bar at the top of the Plugins           page. 

   4.  Install the Integration-Multiple Provider Single Sign-On Enhanced UI Plugin as shown below. 

Note: Plugins are automatically activated post installation. 

   5. Search for Multi-Provider SSO in the Filter navigator (top left input field). Click on Properties Button. 

    6.  Select Yes for Enable Multiple provider SSO, as shown below & Click Save. 

    7. Search again for Multi-Provider SSO in the Filter navigator (top left pane). Select Identity                                Providers.

     8. Click New and select SAML for SSO Configuration provider. 

     9. Import the Identity Provider Metadata from Okta. 

     10. After Importing the metadata, automated SAML settings are populated. Check Default for Default                   SAML Settings.

    11. Under the Encryption & Signing Tab, Set the Signing/Encryption Key Alias as “saml2sp”.

    12. Select the User Provisioning Tab and Uncheck Auto Provisioning User and Update User Record Upon         Each Login checkboxes. 

    13. Select the Advanced Tab, In the user field, specify the ServiceNow user attributes that you will be                 matching against Okta with SAML. We are using email as the user field. 

    14. Check Create AuthnContextClass box as shown below. 

      15. Scroll Up and click Test Connection button. You are all set. 

   16. Activate the partnership 

       Thanks a lot !!!

OAuth 2.0: Implicit Grant Flow & Why you should stop using it !!!

OAuth Implicit grant Flow

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

The Implicit Grant Type is a way for a single-page JavaScript app (SPA) to get an access token without an intermediate code exchange step. The primary reason the Implicit flow was created was because of an old limitation in browsers, that JavaScript could only make requests to the same server that the page was loaded from. 

However, the standard OAuth Authorization Code flow requires that a POST request is made to the OAuth server’s token endpoint, which is often on a different domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit flow worked around this limitation by avoiding that POST request, and instead returning the access token immediately in the redirect.

Well, in the old days (back in 2010) browser-based apps were restricted to sending requests to their server’s origin only. So there was no way to call an authorization server’s token endpoint at a different host. That’s why the short cut was introduced to deliver the access token in the authorization response through the browser. The risks associated with this approach should be mitigated by limiting the privileges and lifetime of such tokens. The implicit grant has always been a compromise!

The below diagram explains the Implicit grant flow. 

The flow illustrated in Figure above includes the following steps:

1. The client initiates the flow by directing the resource owner’s user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
2. The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client’s access request.
3. Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment.
4. The user-agent follows the redirection instructions by making a request to the web-hosted client resource (which does not include the fragment per [RFC2616]). The user-agent retains the fragment information locally.
5. The web-hosted client resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI including the fragment retained by the user-agent, and extracting the access token (and other parameters) contained in the fragment.
6. The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token.
7. The user-agent passes the access token to the client.

Why we should stop using it?

In case of Implicit grant type is that the access token is returned in the URL directly, rather than being returned via a trusted back channel like in the Authorization Code flow. The access token itself will be logged in the browser’s history, so most servers issue short-lived access tokens to mitigate the risk of the access token being leaked. Because there is no backchannel, the Implicit flow also does not return a refresh token. In order for the application to get a new access token when the short-lived one expires, the application has to either send the user back through the OAuth flow again, or use tricks such as hidden iframes.

The implicit grant’s security is broken beyond repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user’s health record or initiating a payment, from her bank account.


Moreover, increasingly complex and dynamic usage scenarios require an additional security layer called sender constrained access tokens to prevent malicious reuse of access tokens. Unlike bearer tokens, where anyone in possession of a token can use it, sender constrained access tokens require the sender of a request to demonstrate possession of a private key the access token is bound to. Unfortunately, the implicit grant cannot easily be extended to support this more secure token type.

OAuth Authorization Code Grant Flow !

OAuth Authorization Code Grant Flow

Authorization code flow is the most flexible of the three supported authorization flows and is the recommended method of obtaining an access token for the API.The Authorization Code grant type is used by web and mobile apps. This authorization flow is best suited to applications that have access to secure, private storage such as web applications deployed on a server.

Access tokens, obtained using authorization code flow, provide permissions for your application to manipulate documents and other resources on behalf of a user (Resource Owner) and make requests for all API resources. Access tokens while having a limited lifetime, can be renewed with a refresh token. A refresh token is valid indefinitely and provides ability for your application to schedule tasks on behalf of a user without their interaction.


Authorization Code Flow diagram:

Following are the parameters in HTTP request using Authorization Code Grant Flow.

• response_type=code - Indicates that your server expects to receive an authorization code
• client_id - The client ID you received when you first created the application
• redirect_uri - Indicates the URI to return the user to after authorization is completed.
• scope - One or more scope values indicating which parts of the user's account you wish to access.
• state - A random string generated by your application, which you'll verify later. This value must match the value your application supplied in the URL creation step to protect against CSRF attacks.

In the Authorization Code grant Flow, when the user clicks on the Login Button, The application should warn users & they will be asked to authorize using their user account before initiating an action that requires authorization because user's web browsers will redirect to another site. This phase is called the consent phase. 

The webapp then initiates the Authorization code request to the /Authorize Endpoint of the Authorization Server using the above mentioned parameters. 

Once it receives the Authorization Code from it then hits the /token Endpoint with Client_Id + Shared_Secret + Authorization Code . The Auth Server validates the client_Id, shared_secret & the access Code, once validated Auth Server issues the Access Token. 

The app then can use the access token to access the resource server data. 

A successful refresh response body is JSON data containing the replacement access token. The JSON object contains the same properties as the result of the original access token response.

{
    "access_token": "MSwxN1zZPUxsLIzDM1wMJWEdDaTZiNNzMsYLDEdzcXNDY4NzaSzDA4Sw3QWCxFYFBZ0ZWzN3NzMZ3MWp5GM",
    "expires_in": 3600,
    "refresh_token": "MSwxMDM3MzRU3OUMktdmTsZpCDveWT5XMxQOG1SQTtNzczLVUcHOzNADEsbwGFV",
    "token_type": "bearer"
}

Note: A new refresh token may be issued during the process to obtain a new access token. Your application should discard the previous refresh token and store the new value. Ensure your application stores the new value securely.

OAuth - Client Credential Flow!!!

OAuth Client Credential flow with API Gateway:

The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. This is typically used by clients to access resources about themselves rather than to access a user's resources.  
The Client Credentials grant is used when applications request an access token to access their own resources, not on behalf of a user. The client needs to authenticate themselves for this request. Typically the service will allow either additional request parameters client_id and client_secret, or accept the client ID and secret in the HTTP Basic auth header.

Below diagram explains the client credential flow in general along with the API Gateway.

Note: The API Gateway can be AWS API Gateway or Azure API gateway or any other API gateway.  The API gateway is acting as a proxy to the backend API's. 

The client will send its client_id & shared Secret to the Authorization Server  (/token Endpoint) in HTTP request & will receive the Access Token directly in HTTP response.  

The same access token will be sent to the API gateway (which is proxying the backend API's. we can have the logic of validation in the API gateway & once the Access token is validated client can access the backend API's or Microservices. 

Example 

A sample client credential Grant Type request looks like below. 

HTTP Request:

HTTP Response:

A sample HTTP response for the above request may look like this. 

Access Token: 

The access token which is received is a Bearer token. that means anyone who has that token can access the API. Refresh Token is optional. Refresh token has a longer life time than the Access Token.