Explore Authentication Flow

Angular Java Sample App configuration and authentication flow exploration

This guide aims to help the user in understanding and configuring the Settings page and explain the authentication flow in CyberArk Identity sample app.

Configure Sample App Settings

After completing the deployment as mentioned in previous section, user needs to build and run the app as suggested in README.

  • CyberArk Identity sample app's Settings page provides a GUI form based page to help user in updating the application related data which was configured in Tenant Configuration.
  • Open any browser and go to url which is configured as part of deployment. In this case, we use https://identitydemo.acmeinc.com:4200
  • Click on the Settings link as highlighted in the above image.
  • Update the settings form with the data obtained while configuring tenant. For further reference click here.

Application Logo

Any custom image can be uploaded with the supported png, jpg, gif, ico, bmp image file types.

Image will be auto-scaled accordingly.

CyberArk Tenant

Attribute

Description

Sample Input

URL

Provide the tenant URL that was created in Tenant Creation section

https://aamxxxx.my.idaptive.qa/

The URL must be https protocol.

Login Suffix

Navigate to suffix section under settings->customization->Login section to identify your tenant login suffix.

aajXXXX

The red highlighted box in the below image indicates login Suffix

Role Name

Provide the role name that was created in Tenant Creation section. This role is mapped with the policies which are linked with webapps.

MFA

The green highlighted box in the below image indicates Role name

OAuth 2.0

Attribute

Description

Sample Input

Application ID

Provide the oauth app name that was created in Tenant Creation section. We can find this value in OAuth2 Client app Settings page.

oauthclient

Username

Provide the non interactive service user details that is linked with the webapp. The username needs to be suffixed with login suffix.

[email protected]

*Scopes**

Provide the scope name that was used while creating Outh webapp scopes in Tenant Creation section as mentioned below.

all

OpenID Connect

Attribute

Description

Sample Data

Application ID

Provide the OpenID Connect Application ID that was provided in Settings section of OpenID Connect web application.

CRMApp

Client ID

Provide the Client ID available in Trust section of OpenID Connect web application in the tenant that was created. Please ensure that client ID should be in GUID format. For reference please check below image.

bf754b97-ae3a-4309-9565-eb6993041b3d

Scopes

Standard OpenID Connect scopes are openid, profile, email, address and phone. Custom scopes are also supported.

openid, profile, email

Update Settings

  • Upon clicking on Save, details will be successfully saved.
  • User can click on the Home button from the top-right corner of the page to proceed further.

Authentication using CyberArk Identity APIs

The CyberArk Identity provides you with a set of RESTful endpoints that enable you to use CyberArk Identity functionality in your custom applications. You can customize CyberArk Identity Access Management with templates to change the look and feel of your portal. Please refer to the Overview for more details.

To use the CyberArk Identity Platform APIs, user must authenticate to the application. The detailed overview can be found here.

The basic authentication process is as follows:

  1. The client requests authentication for a user by calling /Security/StartAuthentication and passing enough information to identify the user and tenant.

📘

/Security/StartAuthentication

This endpoint updates the server that a user from a given tenant wants to be authenticated. If the user already exists then, the server returns an array of configured security challenges to the client, each containing an array of factors, known as mechanisms, that the user must fulfil for each challenge. The user’s responses to these mechanisms are submitted using the /Security/AdvanceAuthentication endpoint.

/Security/StartAuthentication
{
    "TenantId": "ABC1234",
    "User": "[email protected]",
    "Version": "1.0"
}
  1. The server validates the user, tenant and creates an MFA package that includes other things such as session ID and zero or more authentication challenges for the client to answer.
Authentication Challenge screenAuthentication Challenge screen

Authentication Challenge screen

{
    "ClientHints": {
        "PersistDefault": False,
        "AllowPersist": True,
        "AllowForgotPassword": False
    },
    "Version": "1.0",
    "SessionId": "1e5214e4-0921-4e9e-8ada-3ef2970f7c1f",
    "Challenges": [
        {
            "Mechanisms": [
                {
                    "AnswerType": "Text",
                    "Name": "UP",
                    "MechanismId": "4a23390d-dee9-4ead-aa33-2bacd93f81fa"
                }
            ] 
      }
    ],
    "Summary": "NewPackage",
    "TenantId": "ABC1234"
}

If a server’s response to the /Security/StartAuthentication request contains an array of two challenges, Multi Factor Authentication (MFA) is required to authenticate the user. That is, the user is expected to fulfill one mechanism from each of the Challenges. Please refer to Setup Multi-factor Authenticationfor more details about MFA at product level.

  1. The client calls /Security/AdvanceAuthentication to respond to an authentication challenge.

📘

/Security/AdvanceAuthentication

This endpoint sends the user’s responses of the mechanisms back to the server. Server validates these challenges and it returns an authentication token cookie to the client. Once the client receives the authentication token, the client can use it to invoke subsequent endpoints on behalf of the user.

/Security/AdvanceAuthentication
{
        "TenantId": "ABC1234",
        "SessionId": "1e5214e4-0921-4e9e-8ada-3ef2970f7c1f",
        "MechanismId": "4a23390d-dee9-4ead-aa33-2bacd93f81fa",
        "Action": "Answer",
        "Answer": "Pass1234"
}
  1. If the client answers the challenge correctly, the server does one of the following:
  • Logs the user in and returns LoginSuccess.
  • Requests the user with another challenge mechanism.
  • Notifies the client that an out of bounds (OOB) challenge is pending. The client must poll until the server returns success result.

📘

Note:

After authentication/login is successful, we will receive authentication cookie i.e. .ASPXAUTH cookie as part of HTTP response headers. See Adaptive Authentication for information on API request and response.

After successful authentication, it redirects to Login Protocols page which provides details about all the protocol flows.

For exploring all the 4 protocol cards in detail, please refer the below links.