Access Management 2.0

Objective

Manhattan Active® Platform Access Management 2.0 has an administrative user interface to configure or modify several security aspects, such as the authentication and OAuth client setup. This document describes how you can set up OAuth 2.0 clients for external integration and for calling the REST API.

Before You Begin

You will need access to the Manhattan Active® Platform solution and a Maactive System Administrator role to configure security properties in the Access Management 2.0 administration user interface.

To access the administration UI, go to your Access Management 2.0 URL (https://<unique_id>-auth.<domain_name>/auth/admin/maactive/console/). After you log in, administration UI will look something like this:

The panel is accessible only to the users with the Maactive System Administrator role.

Managing OpenID Connect clients
Clients are entities that request authentication on behalf of a user. Clients come in two forms. The first type of client is an application that wants to participate in a Single Sign On. These clients are only looking for security from Access Management 2.0. The other type of client is the one that requests an access token so that it can invoke other services on behalf of the authenticated user.

Note: In case you have a custom client that you might have created in Access Management 1.0, then you will see that this client should already be migrated to Access Management 2.0. In this case, you will only need to perform client secret updation activity for the same client in the Access Management 2.0 portal. If you have the client’s secret handy, then you can go to the Credentials tab of this client and update the credentials.

If you do not have the secret value, you can create a custom client following the below steps.

Steps

Let’s see how you can create a new OpenID Connect client.

1. Under the Manage menu, click on Clients.

   

2. Click on Create client.

3. Under General Settings, leave the Client type set to OpenID Connect

   

4. Enter a Client ID
   This is an alphanumeric string that specifies ID reference in URI and tokens.

5. Enter a Name for this client.
   Specify the display name of this client.

6. You can optionally give a description of this client in the Description field.

7. Click on Save. This action will create a client for you.

8. Next, under Capability config, we have a toggle button to enable/disable Client authentication. This setting depends on the type of OIDC you would like to create.
    Select ON if the server-side clients perform browser logins and require client secrets when requesting for an Access Token.
    Select OFF if the client-side clients perform browser logins where secrets cannot be kept safe.

   

9. Select Authentication flow as needed. Hover over the question mark ? icon to show a tooltip text that describes which Access Management 2.0 Authentication Flow Maps to which OAuth2 Grant Type.

10. Click on Next.

11. Enter the Valid redirect URIs as needed.
    This is the place where the browser redirects after a successful login.
    NOTE: If you want to use Postman to get an access token using this client for Authorization Code Grant, configure this URL in the Valid redirect URI field - https://www.getpostman.com/oauth2/callback

    

12. You will be redirected to the basic client configuration page. You can review or modify any other details needed on this page.

    

13. In case the Client Authentication was set to true in step 8, you will see a Credentials tab. Click on it. Take note of the Client Secret to be used during the authentication of this created client against Access Management 2.0.

    

14. The next step is to add claims that will be sent as part of the access token, or to be returned during the user info endpoint call. Go to the Client scopes tab. A dedicated scope will be automatically created for this client. Click on this scope.

    

15. This scope will initially be empty. Here is where we need to add the user attributes. Click on Configure a new mapper.

    

16. From this list of mappings, select the User Property mapper.

    

17. In this example, we will see how to configure the “sub” attribute.
    Enter Name as sub.
    Enter Property as sub.
    Enter Token Name Claim as sub.
    Select Claim JSON Type as String.
    Toggle ON Add to access token and Add to userinfo.
    Hit Save.

    

    We can see that the sub claim is now added to this client’s dedicated scope.

    

18. Similarly, you can add other claims as per application requirements. To add another claim, click the Add Mapper dropdown and select the By configuration option.

    

19. Repeat the same steps from 16-18 to map all the attributes (similar to sub attribute) as listed in the table below.

    User Attribute	Token Claim Name	Claim Type	Present in Access Token	Present in ID Token	Multivalued
    sub	sub	String	TRUE	FALSE	FALSE
    organization	organization	String	TRUE	FALSE	FALSE
    userOrgs	userOrgs	String	TRUE	FALSE	TRUE
    bulkOrganizationAccess	bulkOrganizationAccess	boolean	TRUE	FALSE	FALSE
    userBusinessUnits	userBusinessUnits	String	TRUE	FALSE	TRUE
    excludedUserBusinessUnits	excludedUserBusinessUnits	String	TRUE	FALSE	TRUE
    bulkBusinessUnitAccess	bulkBusinessUnitAccess	boolean	TRUE	FALSE	FALSE
    userDefaults	userDefaults	JSON	TRUE	FALSE	TRUE
    userLocations	userLocations	JSON	TRUE	FALSE	TRUE
    largeStoreAccess	largeStoreAccess	boolean	TRUE	FALSE	FALSE
    locale	locale	String	TRUE	TRUE	FALSE
    edge	edge	String	TRUE	FALSE	FALSE
    tenantId	tenantId	String	TRUE	FALSE	FALSE
    userTimeZone	userTimeZone	String	TRUE	FALSE	FALSE
    authorities	authorities	String	TRUE	FALSE	TRUE
    reporting_roles	reporting_roles	String	TRUE	FALSE	TRUE
    user_name	user_name	String	TRUE	FALSE	FALSE

Learn More

• Concept Guides
• Quick Starts

Author

• Shipra Choudhary: Senior Software Engineer, Security, Manhattan Active® Platform, R&D.