Portal 10.4.1: Add enterprise users authenticated via ADFS

[AllWeatherHeather]

We've recently deployed Portal 10.4.1 and we have decided to use ADFS authentication as it works across all the apps we want to use (Collector, Survey123, ArcMap, ArcGIS Pro and browser). When you launch one of these applications the ADFS authentication looks for users with the following usernames: "username". However, when I use the built in tool to "add members based on existing enterprise users" then select "from a group" usernames are automatically generated as username@DOMAIN. These don't line up so users cannot login.

I have explored the "add members for <identity provider name> enterprise logins via SAML" and from here I can specify the username but I also have to enter the name and email address for each user either individually or in a file. This would require I look up each user individually and introduce an opportunity for typos. 

Is there a way to pull new users in without the @DOMAIN added to their username? Alternatively, is there a way to change what the ADFS authentication is looking for so it can understand username@DOMAIN? What are other enterprise implementations doing?

Thanks,

Heather

[JeffSmith]

You'll need to switch the user store and group store configuration types from WINDOWS to LDAP in order to adjust the format of the username.  When the user and group stores are set to WINDOWS, the @DOMAIN is always added to the end of the enterprise usernames that are added through "Add members based on existing enterprise users".  There is not a way to change that.  When you switch to LDAP, you have more flexibility because you can set the "usernameAttribute" to match what is being used in your ADFS configuration.  In your case it looks like you are using the "sAMAccountName".

The hard part about switching to LDAP is determining the correct LDAP URL and user properties that link to your Active Directory.  You may need to contact your domain admin to get that info.  Here is a link to the Portal help doc that goes into detail about the LDAP configuration.  The parameters you'll need to adjust from the example are: user, userPassword, ldapURLForUsers, usernameAttribute, and userSearchAttribute.

[AllWeatherHeather]

Jeff - I've been trying to change the settings you pointed out and haven't been able to successfully get anything to stick. I get Code 500 Error that I could not connect to the user store. Is there any more documentation or examples you can provide to help? For instance, we don't have an ou=users or ou=ags in our environment as described in the ldapURLForUsers property.

Thanks!

[JeffSmith]

Heather,

The ldapURLForUsers property is tough because it is unique to your environment.  Every environment is different.  Your domain administrator should be able to tell you what the values need to be.  The example from the documentation shows: 

ldaps://bar2:10636/ou=users,ou=ags,dc=example,dc=com

In this case, "bar2" is the domain controller.  The domain is example.com and is defined here with "dc=example,dc=com".  There are two OUs in this example; OU=users is a branch or sub-OU of OU=ags.  You don't always need 2 OUs.  In fact you could set the ldap url to not have any OUs at all.  You would likely notice significantly slower performance though because Portal would be searching the entire directory structure for each user rather than specific OUs.    

[JohnFerdetta]

How do we pull the roles directly from the SAML response? Having to go back to the LDAP server isn't secure and is the wrong way to do it, the point of having an Identity Provider is so you aren't going into the user store.

Below is a snippet of the SAML response with the corresponding roles and user name.

<saml2:AttributeStatement>
            <saml2:Attribute Name="http://wso2.org/claims/role"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >Role1, Role2, Role 3, Role4</saml2:AttributeValue>
            </saml2:Attribute>
            <saml2:Attribute Name="http://wso2.org/claims/screenname"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
                             >
                <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string"
                                      >user.screenname</saml2:AttributeValue>
            </saml2:Attribute>
        </saml2:AttributeStatement>

[JeffSmith]

While this is something we are considering for a future release, at this time Portal does not support retrieving role information from a SAML response.

[JohnFerdetta]

Is there a work around that does not involve getting to the ldap server?

[JeffSmith]

The only other option would be to use built-in roles.  This would require an administrator to manage them manually.