You are viewing limited content. For full access, please sign in.

Discussion

Discussion

SAML Okta - Claims Mapping - Group

Directory Server
Updated April 30, 2020
posted on April 21, 2020

A client of ours is attempting to setup Claims Mapping for the SAML Okta Identity Provider. We are unsure about the Groups mapping entry. We have changed 'LDAPDistinguished Name' to 'AD SIDS'.

 

Should the 'Group' just be left as Group? If not, where can we find the attribute that should go there.

 

 

0 0
replied on April 21, 2020

Unless you are using the proxied providers feature (designed for existing Windows users to switch to SAML authenticate), you can leave the setting on "None" rather than AD SID or LDAP distinguished name. We will be updating the label to be clearer in the future.

For Okta, the default attribute name is "group", but I believe Okta does not include the group attribute by default --- it must be enabled by an administrator. See https://help.okta.com/en/prod/Content/Topics/Apps/attribute-statements-saml.htm for instructions.

You can verify whether the attribute is on the token by using the SAML token interception instructions in the documentation.

0 0
View 5 previous replies
replied on April 22, 2020

Thanks Brianna.

The Client is using the proxied providers feature.  Would then using the attribute "group" with AD SID suffice (with the administrator enabling the group attribute in Okta)?

0 0
replied on April 22, 2020

If you are using the proxied providers feature, then you will likely have to do additional work to ensure Okta is passing through the attribute in a relevant format.

The format you select depends on the format you decide to configure in Okta.

A distinguished name will look like "CN=Forms Access Group,OU=Users,DC=YourDomain,DC=com"

An AD SID will start with S-1-5 and be a fairly long string of numbers.

0 0
replied on April 24, 2020

Thanks Brianna.

We are still scratching our heads with this setup. We have engaged Okta Support on a session already and are still unable to make any meaningful head way. Forms still indicates that the user does not belong to a group that is allowed access.

I would like to think that Laserfiche has this working. Is there a way that screenshots on Okta settings are shared? The document in hand doesn't have anything on Groups neither does it have the Proxied Provider. Any further assistance on this will be highly appreciated.

I have copy of the SAML trace and for groups, this is what it is showing:

view sourceprint?
1<Attribute Name="http://laserfiche.com/identity/claims/groups"
2                               NameFormat="urn:laserfiche:names:tc:SAML:2.0:nameid-format:SidAndName"
3                               >
4                        <AttributeValue>S-1-1-0;Everyone;4</AttributeValue>
5                    </Attribute>

 

0 0
replied on April 24, 2020

Ah, it's not the Okta groups you are sending over, so the "group" attribute is not the correct name. My initial response is only correct if you are not using proxied authentication.

Based on the snippet you provided, you should specify the following:
http://laserfiche.com/identity/claims/groups

instead of just the text "group" on the claims mapping page. This is the Name of the Attribute.

Based on the attribute value, you need to select the AD Sid option.

Filling out the claims section should be done by referencing a sample SAML token, since LFDS is always looking at the Attribute Name:

0 0
replied on April 30, 2020

Thanks Brianna.

Are you able to share the following screenshots please? We are not making much headway with the Client's Okta setup with Proxied provider. When we try to login with Client's current setup, through Forms, we get a message that the 'user is not allowed access group for Forms' even though the user account has been added to Forms user access group.

 

From Okta:

  • Attribute Statements for Okta Claims 

 

From LFDS:

  • Claims tab for the Okta IDP
  • Proxied Server Tab
0 0
replied on April 30, 2020

Hi Karim,
 

My Okta settings would not help since this is a custom attribute. The snippet I posted is based on your example SAML token that was posted earlier.

Taking the information from the customer's SAML token and putting it into the UI would look like (please ignore claims other than groups; I have simply put in placeholder values):

 

I cannot provide an example of the proxied providers tab because I do not have that part of the customer's SAML token.

Since this is information you should be taking from the SAML token based on their configuration, there is not a standardized value that we can provide/document.

The text box portion is the exact same thing as the value for the Name element in the SAML token. The format dropdown should reflect what is shown in the value: in your example, it's AD SID formatted. My developers confirmed that the "Everyone" value there should not cause problems.

Note that if the user account has been directly added to a LFDS group, then the group attribute mapping is not the issue. It may be that the user is not being mapped. 

To troubleshoot group membership and whether the user is mapped, use the claimstest page by having the user navigate to 
https://yourSTSmachinename.com/LFDSSTS/claimstest

It should show a list of all groups the users belongs to as well as the SID LFDS has for that user. The SID on that page should match the AD user SID, and the groups should match the groups SID list you provided earlier + any LFDS groups they belong to.

If you are still having troubles, a support case would be the best way to proceed.

0 0
replied on April 30, 2020 • Show version history

Brianna,

Here is the claimstest results. The groups do match with what was provided earlier. It doesn't include any LFDS group as far as I can tell. It seems that the User's AD SID (S-1-5-21-#########-##########-##########-###) is different from what is in the Claimstest (S-1-9-122#####-##########-##########-#########-#########-#).  I guess this is the issue. Any ideas how we tack this?

 


Moderator note: edited to redact most of the SID. The beginning is sufficient to show the difference and the texts of posts on Answers are visible to the public.

0 0
replied on April 30, 2020

It means that the identifying attribute LFDS knows about for the user does not match the attribute included on the token. For proxied providers for AD identity providers, LFDS uses their AD SID.

This may mean:

  1. You have the proxied provider "Identifying Attribute" incorrectly configured.
    Like with groups, what this is for your customer can be determined by looking at the incoming SAML token.
    Unless the SID is in the "NameID" section, you want to use the value of the Name element on the appropriate attribute. It seems probable that you want the AD SID format given that the groups are in that format (rather than encoded)
  2. Okta is not sending over what you think it is --- again, determine this by looking at the SAML token. It could be that the attribute isn't being included, or that the mapping in Okta is incorrect and the wrong value is incldued.

 

Just like with groups, you must send over the AD SID on the SAML token for the the user to get proxied authentication to work. 

Bert Warren posted about this here: https://answers.laserfiche.com/questions/170354/AzureAD-and-AD-accounts#170370

And I've attached my powerpoint from a relevant course at empower (trimmed somewhat to fit as an attachment).

If that post and the instructions in the attached powerpoint do not help, please open a support case.

IT Admin 304 Advanced Topics in Identity Management_trimmed.pptx (1.63 MB)
Download
0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...