[New post] Working with Portal for ArcGIS authentication: Enterprise groups, the Portal Administrator Directory, and SAML
razimosadeghi posted: " A brief background When managing authentication with your chosen identity store in Portal for ArcGIS, authentication can be configured at the Portal tier or the Web tier. The primary differences from a user experience perspective being Portal tier req"
When managing authentication with your chosen identity store in Portal for ArcGIS, authentication can be configured at the Portal tier or the Web tier. The primary differences from a user experience perspective being Portal tier requires credentials to be provided to sign in and it does not support a Single Sign On (SSO) experience. Web tier can be configured to utilise the ArcGIS Web Adaptor, Microsoft Internet Information Services (IIS), and Integrated Windows Authentication (IWA) for a SSO user experience.
If using an enterprise identity store with Portal tier authentication, by its nature it requires a closer integration with your Microsoft Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) compatible identity store. When a user enters their credentials to the Portal for ArcGIS sign in page, the credentials are passed to the portal application which then handles the process of authenticating the credentials with the configured enterprise identity store before signing them in.
If using an enterprise identity store with Web tier authentication, the ArcGIS Web Adaptor and IIS configured with IWA enabled handle the authentication of credentials rather than the portal application, enabling a SSO experience. It can also be configured with the Java ArcGIS Web Adaptor and LDAP, for utilisation in a Linux environment for example.
Becoming a popular option, Portal for ArcGIS supports integration with identity providers compatible with Security Assertion Markup Language (SAML) 2.0 authentication, a form of web tier authentication but referred to as an external tier authentication method. Similar to web tier, authentication is handled on a web server but usually an external web server to the ArcGIS Enterprise deployment. Common scenarios include the utilisation of external identity providers such as Microsoft Azure Active Directory, Microsoft Active Directory Federation Services (ADFS), Okta, and others. Comparative user experiences would include utilising a Google, Facebook, Apple, or GitHub account to sign in and access other websites or services such as ArcGIS Online.
SAML is becoming a popular and prevalent security setting for Portal for ArcGIS due to the various security benefits, enabling a seamless Single Sign On (SSO) experience, and the ability to support multiple identity providers (both built-in and enterprise accounts).
Implications of SAML on the Portal Administrator Directory
Let us assume we have set up our Portal for ArcGIS with SAML authentication to an external identity provider. We have our enterprise users and groups configured as per Configure a SAML-compliant identity provider with a portal—Portal for ArcGIS | Documentation for ArcGIS Enterprise. Now we are looking at how we can interact with our enterprise users and groups through the Portal Administrator Directory endpoint. However, attempting to utilise the "Get Enterprise Groups for Users" operation through <portalurl>/webadaptor/portaladmin /security/groups returns error code 500:" An enterprise group may not have been configured or we were unable to connect to it. Please check the logs for more information."
We also attempt to use a Python script to automate the process of adding SAML users to portal, we are using an administrator account but the Generate Token request to the ArcGIS REST API still returns a 400 error! What could be the reason for all these errors?
Why? Simply, this is expected behaviour by external tier authentication.
When we configure SAML authentication with our enterprise identity provider, login requests to portal are redirected to the external identity provider via SAML. Upon successful login the SAML response is used by Portal for ArcGIS as authorised and trusted credentials to sign in. The external identity provider cannot be integrated via SAML as the Portal for ArcGIS user store and group store configurations.
The "Get Enterprise Groups for Users" and "Get Users Within Enterprise Group" only operate on configured user and group store configurations. These back-end operations only work with portal tier and web tier authentication scenarios. It does not currently support external tier authentication configuration such as SAML.
The following conceptual workflow demonstrates how the login requests are managed between Portal for ArcGIS and SAML (Step 2).
If we explore our Portal for ArcGIS security configuration through <portal url>/webadaptor/portaladmin/security/config we will see the group store configuration in our Portal for ArcGIS identity store are still set to "BUILTIN" type even though we have set up SAML enterprise logins. Basically, Portal for ArcGIS defers users to the SAML identity provider and trusts the assertion provided on behalf of the user. Rather than the username / login being handled by the Portal for ArcGIS built-in identity store, it is handled by the SAML identity provider.
Groups and Users operation on the Portal Administrator Directory endpoint are designed to interact with enterprise authentication at the web tier and portal tier, where we need to update our Portal for ArcGIS identity store with LDAP or AD users and groups. With this configuration, we will need to update group store configuration directly, using the JSON text mentioned in the following link: Use your portal with LDAP or Active Directory and portal-tier authentication—Portal for ArcGIS | Documentation for ArcGIS Enterprise.
In this scenario our Portal for ArcGIS uses the Microsoft Windows AD as its group store identity. Therefore, the "Get Enterprise Groups for Users" and "Get Users Within Enterprise Group" operations will return a valid response. Step 4 on the following picture demonstrates conceptually how Portal for ArcGIS accesses AD or LDAP identity stores to authenticate the login requests.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.