ForgeRock OpenAM - Authentication Trees !!!

What could I build with Authentication Trees?

Short answer — a lot!

In the First Article, I have covered some cool things you can do with the Out-Of-The-Box nodes, we will also see how to create custom nodes or access a wealth of custom nodes created by the community.

A simplest way to Implement your own business Logic in a node is by using Scripts in ForgeRock. You can easily write a custom script either in JavaScript or GoovyScript to perform some evaluation & determine the outcome. 

First we will create a Script, to do this navigate to the realm which you have created or to the Top Level realm. 
for e.g.
http://demo.test.com:8080/am/XUI/?realm=/#realms/%2Ftestrealm/scripts

Then Click on the Scripts on the Left Hand Navigation Pane. 

Click on the New Script Button & Enter the name of the Script as shown below. 

Now you need to enter your code & business Logic. you can choose either the JavaScript or GroovyScript. In this example, I have chosen the JavaScript. 

Click on the Validate Button to validate your code & then Save Changes. 

Note the name of the Script & we will use it in our AM Trees. 

Navigate back to the tree we created earlier, and drag a Scripted Decision Node onto the canvas and connect it up. Then select the script and ensure that the outcomes we define in the script (true and false), are entered in the Outcomes field. 

You can now try authenticating again using trees.  
This is very simple example of using Scripts in Node.  common uses of these are calling out to third party services, taking the result and evaluating it to determine an outcome. You can use this as a starting point to develop something more sophisticated.

There are lot of custom examples available on ForgeRock Market Place.

https://backstage.forgerock.com/marketplace/catalogDisplay



Thanks a lot !!!

Multi Factor Authentication - why is it essential for Every Organization !!!

The threat to the organizations is increasing because Organizations are forced to enforce Work from Options to the Employees. multi-factor authentication (MFA) has rapidly gained adoption as a method for increasing the assurance of authentication/authorization for customers.

Authentication is generally accomplished by validating one of three types of factors as mentioned below.

1. something you have (e.g. an user-ID card)
2. something you know (e.g. a username/Password)
3. something you are (e.g. a Fingerprint/Biometric Identification)

Multi-factor authentication employs the combination of two or more types of above mentioned factors.

There are multiple ways to increase the security of your MFA feature. some of the useful Tips have been given below.

1. Understand and manage the vulnerability of your account recovery flow.
2. Protect your login flow from brute force attacks.
3. Design to manage trade-offs between risk, usability, and cost.

We will discuss the all three in detail.

Understanding & Manage the Account recovery flow:

Always separate the recovery of the second factor from the recovery of the primary factor. Should an attacker gain access to primary authentication factor, the second factor becomes immaterial if it can be reset with possession of just the password. Further, the recovery flow for the second factor should be completely separate from the recovery flow for the password.

For example, If an email message is the method for recovering the password, make sure to recover the second factor through an altogether separate channel.

Involve an administrator wherever required. An administrator can in many scenarios implement a sophisticated high assurance authentication method.

In enterprise scenarios, companies will be in the best position to authenticate members of their own organization through shared secrets derived from the content of the employee’s work or profile, the company, and human relationships. One notable approach is to ask an employee’s manager to authenticate the user and then authorize staff to execute the MFA reset.

Protect your login flow from brute force attacks:

As the availability of inexpensive computing resources increases so does the vulnerability of authentication systems to brute force guessing attacks. However several simple techniques can be used to significantly improve the security of your multi-factor authentication in the circumstance where the password has been compromised.

• Login flow sequence
• Rate limits
• Account Locking

For e.g. Placing the challenge for the second factor on a page beneath the login page has two benefits.

• It protects your user from an attack aimed at locking them out of their account once a failed login attempts limit is reached (with rate limits applied to the primary factor).

• Obscuring the second factor provides an attacker with less visibility into another layer of security. Always Implement a rate limit and lock policy on the second factor. The probability that a user enters their token incorrectly multiple times is low. As such, your suspicion of attack should grow with each failed attempt. Response times should grow with each subsequent attempt to decrease the aggregate number of attempts possible per unit time, with a complete account lockout (where feasible) upon several consecutive failed attempts. For time-based second factors, manage rate limits according to the life of the token.

Logs and alerts

Collect and analyse all unsuccessful second factor attempts. In the event of several failed second-factor challenges, alert the user or an administrator of this suspicious behaviour, and prompt the user to enrol for a new token.

Always Use an out-of-band token. A second factor that is verified through a channel separate from the primary factor adds extra protection against brute force attacks (and phishing).

For example, a popular new factor sends the user a push notification on a mobile phone with details about the authentication request and a prompt to accept or deny the request. This channel is inaccessible to a traditional brute force guessing approach.

Design to manage risk, usability and cost:

The design of a multi-factor authentication feature will have significant implications on security, usability, and cost in any context. A higher assurance second factor can in some cases present the burden of increased hassle for end-users and administrators which can impact the adoption of MFA for your product and thereby decrease security. There are some best practices for balancing risk, usability and cost. Offer a spectrum of options to serve diverse user populations. Different user populations present different levels of risk and hence, warrant different levels of assurance. For example, an administrator can have a larger scope of access than an individual user. As such, you may wish to provide relatively stronger second factors for administrators, while offering more convenient options for users. In consumer scenarios different users will have different preferences and a lower assurance more convenient option that is actually used may provide more security than a high assurance option that lacks adoption.

Support federated authentication: In enterprise scenarios many companies are implementing authentication and MFA locally for identities they manage, and federating to resources. This approach allows product development teams to outsource administration of policy and security processes to customers. Multi-factor authentication is only as secure as its account recovery flows. In many highly publicized recent cases, attackers have been able exploit vulnerabilities in the account recovery process to gain control of an account. For example, A web application provides for MFA based on a soft token app installed on a user’s phone and allows the user to enrol a phone number for the purposes of receiving a backup second factor for account recovery in the event that the user is unable to access their soft token. The strength of second factor now depends on the strength of the telecom provider’s processes for authenticating the customer and forwarding calls or SMS. Will the attacker be able to impersonate the user and convince or pressure a customer service rep to route calls or SMS to a number she controls? Every second factor will need a method for replacement, and so this begs the question of how to develop secure recovery flows as mentioned above.

Thanks a lot !!! :-)

Cheers !!!

Authentication Trees - ForgeRock !!

Authentication trees were introduced in ForgeRock openAM version 6.x or later. Authentication trees are made up of authentication nodes, which define actions taken during authentication, similar to authentication modules within chains. 
Authentication trees (also referred to as Intelligent Authentication) provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow.

Email Based HOTP Authention Tree: Below example shows the Email based 2 factor authentication tree using gmail. 

Collector Nodes: Collector nodes capture data from a user during the authentication process. This data is often captured by a callback that is rendered in the UI as a text field, drop-down list, or other form component.
Examples of collector nodes includes the Username Collector Node and Password Collector Node as shown in above picture.

Decision Nodes: Decision nodes retrieve the state produced by one or more nodes, perform some processing on it, optionally store some derived information in the shared state, and provide one or more outcomes depending on the result.

The simplest decision node returns a boolean outcome - true, or false.

Example of the Decision nodes includes the Data Store Node as shown in above picture. 

HOTP Generator Node:  This node is used to generate the OTP over the email with a validity period. 

OTP Email Sender Node: This node is used to send the OTP via Email. I have used the Gmail as the mail sender.

To send emails using Gmail server enter these details:

SMTP Host: smtp.gmail.com
SMTP Port: 587
SSL Protocol: OFF
TLS Protocol: ON
SMTP Username: (your Gmail username)
SMTP Password: (your Gmail password)

Also make sure your "From email address" in HESK settings is set to your Gmail email address!

Note: Make sure that the SMTP port 587 is opened from the host computer. 

OTP Collector Decision Node: This node is used to collect the decision of OTP. As described above, The collector node output is either True or False. we have pointed True as Success & False as Failure. 


Once you Save the above Authentication Tree (mytree) access the following URL. 

URL: https://myserver.test.com:8080/am/XUI/?realm=testrealm&service=mytree


Output: After Entering the Username & Password, You should be asked to enter the OTP received on your Gmail. Once OTP is verified, Access is allowed. 


All the very Best. !!!

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.