Access Management 2.0 FAQ

Access Management 2.0 Frequently Asked Questions

Objective

Access Management 2.0 is the next feature-rich version of the Manhattan Active Platform Identity & Access Management (IAM). It introduces new capabilities such as support for multiple Identity Providers (IdPs), OIDC JIT, and more flexible UI/API configuration options, all while maintaining backward compatibility with the current version of the Manhattan Authorization Server. This page provides a list of the most Frequently Asked Questions (FAQ) along with their answers.

Does it support native Organization Database Users’ login?

Yes, it does. Access Management 2.0 (AM 2.0) natively supports the database users that Manhattan Active products maintain in the Organization Component/Organization Database.

Does it support Multiple Identity Providers?

Yes, it does. Support for multiple Identity Providers has been a frequent request from many Manhattan customers. Access Management 2.0 now fully supports this feature through simple configuration, without requiring any additional code changes.

Does it support SAML 2.0 Just In Time User Creation/Updates?

Yes, it does. Like its predecessor, the legacy Authorization Server, Access Management 2.0 continues to support SAML 2.0 Just-In-Time (JIT) user creation and updates in the Organization Database. While the legacy Authorization Server relied on KV Store property configurations to achieve this functionality, Access Management 2.0 introduces a customer-facing Admin User Interface for configuring SAML 2.0 Identity Providers (IdPs) with JIT or non-JIT features.

Does it support OIDC Just In Time User Creation/Updates?

Yes, it does. Unlike its predecessor, the legacy Authorization Server, which did not support OIDC JIT, Access Management 2.0 fully supports OIDC 2.0 Just-In-Time (JIT) user creation and updates in the Organization Database. It also introduces a customer-facing Admin User Interface to configure OIDC Identity Providers (IdPs) with either JIT or non-JIT features.

Does AM 2.0 Support Custom Branding and Styling?

Yes, it does. Access Management 2.0 includes a Custom User Interface within the Admin UI, allowing users to provide custom style sheets to tailor the look and feel of the platform. Customers often request changes to the standard logo, background image, and footer to align with their branding. A detailed step-by-step guide is also available to assist the Services team.

Does AM 2.0 support Multiple Locales?

Yes, it does. Access Management 2.0 supports over 20 locales out of the box. The desired locale can be easily changed through the Admin UI. Additionally, Access Management 2.0 can dynamically detect browser headers to automatically adjust for localization.

Does AM 2.0 support all Existing Standard Clients in the Legacy AuthServer?

Yes, it does. The legacy Authorization Server supported 13 standard clients, all of which are also supported in Access Management 2.0. For existing customers, these clients are migrated automatically, while for new customers, they come pre-seeded.

Will the switch over from existing AuthServer to AM 2.0 migrate existing standard and custom clients and what are the caveats?

All standard Manhattan clients will be migrated along with their client secrets. Custom clients will also be migrated but without their client secrets. Customers can either update the client secret for a custom client or create a brand-new custom client to meet their external application integration needs.

Does AM 2.0 support Custom Client creation?

Yes, it does. There is a customer-facing help page in the Manhattan Developer Hub that provides a step-by-step guide on creating custom clients, mapping attributes, updating client secrets, and more.

Does AM 2.0 support special characters like the + sign in the Client Secrets?

Yes, it does. If there is one or more + signs in the client secrets, users have two options:

  • Option 1: Pass the client secret in its verbatim form within the request body, e.g., using the Body tab in Postman.
  • Option 2: Use the Authorization tab in Postman, select Basic Auth, and URL-encode the + character by replacing it with %2B.

How to avoid Users originating from the Customer’s Identity Provider receiving Password Reset Email.

This can be done by setting this property “manh.security.login.identity-type” in the KV Store to mixed.

Does it support the Resource Owner Password Grant aka Password Grant?

The Manhattan Standard Client for Postman no longer supports the Password Grant due to security considerations. Manhattan recommends using the more secure Authorization Code Grant for tools such as Postman. Access Management 2.0 supports the Authorization Code Grant by default. However, if a customer requires Password Grant support, they can create a custom client with Direct Grant support enabled.

Does Access Management 2.0 support the Password Grant with a username and password sent via the Request URL?

No, it does not. Using the Password Grant this way is considered a security violation. The Password Grant was originally intended as a temporary OAuth2 grant type, designed to be replaced by the more secure Client Credentials Grant.

Is there any customer-facing documentation for Custom Client Creation?

Yes, there is one, located here Access Management 2.0.

What is the information needed from the Customer’s Security Admin for IdP Configuration?

For an OIDC Identity Provider, the following are needed:

  • The well-known URL provided by the OIDC IdP
  • The Client ID
  • The Client Secret

For SAML 2.0 Identity Provider, the following are needed:

  • The IdP Metadata URL.
  • Manhattan needs to provide the Service Provider (SP) Metadata URL to the Customer.
  • The Signing and Encryption Keys need to be given and configured in the Customer SAML 2.0 IdP.

Does AM 2.0 support Custom Access Token Lifespans?

Yes, it does. In special cases, this can be configured in the Access Management 2.0 UI. However, if there is a request to extend Access Token lifespans, please reach out to R&D for further discussion and approval.

Does AM 2.0 support different levels of Admin UI Access?

Yes, it does. Access Management 2.0 supports two types of administrators:

  • Full Administrator: Has permissions to access, edit, and delete all configurations.
  • Restricted Administrator: Has limited access and can manage only Clients and Identity Providers.

Does AM 2.0 support two Signing/Encryption Keys for Access Tokens and SAML 2.0?

Yes, it does. Access Management 2.0 supports the use of two keys: one for internally signing JWT access tokens and another for integrating with the customer’s SAML 2.0 Identity Provider (IdP). For more details or specific requirements, please reach out to R&D for further discussion.

Does AM 2.0 support Auditing/Event Publishing to Activity Stream?

Yes, it does. While the legacy Authorization Server supported Activity Stream Event, Access Management 2.0 expanded the coverage to include

  • Authentication Failures (401) and Authorization Failures (403)
  • Postman Login
  • Identity Provider Login Success and Failure
  • Native DB Login Success and Failures
  • Password Reset / Set / Change Events

Does AM 2.0 support Password Reset/Forgot Password/Change/Set Password?

Yes, Access Management 2.0 supports the full range of password management use cases, including Forgot Password, Change Password, Set Password, and Reset Password. It is fully integrated with the existing component-organization to facilitate these functionalities.

Does AM 2.0 support Role Based Access Control for Org. DB Users and External IdP Users?

Yes, it does. Like the legacy Authorization Server, Access Management 2.0 fully supports RBAC and is 100% backward compatible in this regard.

Does AM 2.0 allow Manhattan Employees to log in as DB Users?

No, it does not. Access Management 2.0 mandates that all Manhattan employees authenticate using the Manhattan Azure IdP, which is configured in the Admin UI. However, a small whitelist of robot users with the manh.com suffix is permitted to ensure operational effectiveness.

Does AM 2.0 support Voice-Enabled Devices?

Yes, it does. Access Management 2.0 supports the Voice device from a few vendors. Please check with your Service Representative.

Does AM 2.0 support Android and iOS Store Applications?

Yes, it does support both the Android and iOS versions of the Store Application.

Does AM 2.0 support MHE Authentication?

Yes, Access Management 2.0 supports MHE integration.

What role do Manhattan employees play while authenticating using the Manhattan Azure IdP?

Customers are still required to authorize Manhattan employees for access, even though the employees authenticate against the Manhattan Azure IdP. Roles for these employee users are still validated against the Organization Database.

Does AM 2.0 support the User Discovery Mode of the Legacy AuthServer?

No, it does not. Access Management 2.0 supports a single Login Page that provides multiple options for Login. Users can easily choose the native database login, the Customer IdP Login, or the Manhattan Employee Login.

How does AM 2.0 support Multiple IdP Authentication in the UI?

Access Management 2.0 supports a single Login Page customizable for the background image, footer, logo and other styles. Users can easily choose the native database login, the Customer IdP Login, or the Manhattan Employee Login.

How does AM 2.0 support the mapping of User Attributes from External Identity Providers?

Access Management 2.0 supports the mapping of standard user attributes (documented separately in the Developer Hub) through the Mapper tab in the Identity Provider Configuration. It allows the mapping of both single-valued attributes and multi-valued attributes (e.g., roles) represented as comma-separated values. User attribute mapping functions consistently, regardless of the underlying protocol (SAML 2.0 or OIDC).

Does Access Management 2.0 have the userOrgs claim as part of the Access Token?

Access Management 2.0 always includes all mandatory and optional claims as part of the Access Token, aligning with industry standards. If the legacy Authorization Server returned claims outside of the Access Token, users have two options:

  • Option 1 Extract the UserOrgs from within the Access Token.
  • Option 2 Call the /{url}/authserver/api/authserver/user endpoint separately to receive the id token which will include all claims.

How to avoid the HTTP 413 Request Entity too large/Payload too large errors?

When an OAuth2 client, such as a Spring Boot REST API / UI, calls another REST API with a Bearer Token in the Authorization header, and the token is excessively large (e.g., a very large JSON Web Token or opaque token), it can lead to an HTTP 413 (Payload Too Large) error in the following scenarios:

  • Header size limit exceeded:

    • The Authorization header containing the Bearer Token contributes to the total size of the HTTP request headers.
    • If the token is excessively large, it may exceed the maximum allowed header size configured on the target REST API server or an intermediate gateway (e.g., Nginx, AWS API Gateway, or a firewall).
    • Most servers enforce limits on header sizes to prevent abuse or resource exhaustion.

  • Token encoded as JSON:

    • If the token is a JSON Web Token (JWT), it includes a payload that might encode a large number of claims, roles, or other metadata.
    • For example, a JWT may include user roles, scopes, or custom claims, making the token size grow beyond typical limits.

  • How this causes HTTP 413

    • The server (or an intermediate gateway) immediately responds with an HTTP 413 Payload Too Large error, indicating it cannot process the request.
    • This happens before the request body is even processed, as headers are inspected first during request parsing.

  • How to avoid HTTP 413:

    • If the User whose Access Token generates the HTTP 413 has a large number of Roles, Org, etc., please call the following endpoint after the authentication call /{url}/authserver/api/authserver/user

Last modified December 3, 2024: Approved staged content - automated-patch-2024-12-12-promotion.patch (486d1aa)