Handling multiple Claims in SAML Authentication

Certified Lead Developer

Hi All,

We came across a situation where we need to implement SAML for Internal and External user groups of our organization. Our Appian environment holds Employee ID as Appian Username for Internal Users and Email ID as Appian Username for external users.

Our Identity Provider might be able to provide both the information,  Employee ID and Email ID as Name ID of the Subject. 

Our Internal users and external users are placed in 2 different groups and there is a parent group where both the Internal and External groups are member groups. Authentication Group is set to the Parent group as this needs to work for both member groups.

For the above setup, we are aiming to implement SAML Authentication. In Appian,  is there a way to dynamically choose the Name ID based on the group the user belong to? For example if the user belongs to internal users group, we need to compare the Employee ID against Appian Username, If the user is from external user group, we need to compare the email ID with Appian Username(as external users doesn't have employee ID)

(One Idea we came across is to create 2 separate SAML Integration for same Identity Provider, However Appian doesn't allow adding same identity provider twice (even if the Authentication group is different))

Please let me know if above details are not fully clear or if more information is required to understand this.

Thanks in advance,

Arjun.

  Discussion posts and replies are publicly visible

Parents
  • Configuring two IDP:

    Appian checks the entity Id in the IDP metadata to identify each IDP. So please check if your IDP can provide metadata XML with dynamic entity ID for each service provider configured.

    However if you are using Azure AD as SAML provider, the above method is not possible because the Azure AD Identifier is the entity ID and it cannot be modified.

    Dynamic Attribute matching for username:

    Unfortunately, Appian cannot dynamically choose a SAML attribute to match against Appian username. it had to be fixed attribute.

    Though the below options are far from ideal, it might help.

    Check if the external users has any other unique attribute other than email address. Try checking what's the value in UPN and samAccountName attribute for external users.

    If there are other unique fields and if the same attribute contains employee id for internal users, then update the appian username of external users with that unique attribute's value. This will be require a lot of planning if you hold the username in any inflight processes or if it's persisted in any tables.

    But if this can be achieved now, you have both internal and external users with an attribute that matches their Appian username. So now you can use that attribute for username matching.

  • 0
    Certified Lead Developer
    in reply to Raghuvaran Nagarajan

    Hey Raghuvaran, Thanks for taking time to think through this and sharing your thoughts. Since the IDP is custom developed and this could be a common problem statement for other Service Provider systems using the same IDP, at the moment , we are thinking of a possibility to send the Name ID dynamically from IDP itself, depending upon the type of user. In this case, we are not seeing a need to change anything in Appian or any other SP system that is consuming this IDP. 

  • Good to know that you are using a custom IDP. And, I agree that handling NameId in the IDP side is easier

Reply Children
No Data