- Newest
- Most votes
- Most comments
Hello Marcus,
Greetings from AWS Premium Support !
Thank you for contacting us. I understand that you want to have Okta IdP side groups claims in the ID token issued by Cognito for the Okta federated user. Please feel free to correct me in case I have misunderstood your concern.
You need to create a custom attribute in your User Pool [1] and then under the OIDC configuration in your User Pool you need to configure attribute mapping [2] between the Cognito custom attribute and the Okta groups attribute. Also, please make sure that the read/write settings is enabled for your Cognito custom attribute in the App Client settings [3]. With this settings, if your Okta IdP send the group information then you will have that information in the ID token.
I believe the information is helpful to you. If you have any further queries/concerns, then please feel free to reply back. I will be more than happy to assist you.
Wish you an AWeSome day ahead and stay safe ! 🙂
--References--
[1] Create custom attribute in Cognito User Pool
[2] Configure Attribute mapping under OIDC configuration of User Pool
[3] Step 15: "Configure Attribute read and write permissions for this app client"
@Tarit_G - quick update - in my comment above I said we used a public client when it was actually a confidential client
Relevant content
- asked a year ago
- asked 10 months ago
- Accepted Answerasked 3 years ago
AWS OFFICIALUpdated 6 months ago- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 9 months ago
Thank you for the response. You mention: "I understand that you want to have Okta IdP side groups claims in the ID token issued by Cognito for the Okta federated user. " I 'm not fully sure if this is the case. We are not using the SAML Federated Identity provider when we fist built our user pool. We followed a tutorial where we first chose Cognito User Poll over Federated Identity provider, created a public client, then added an OIDC Identity Provider with secret, and finally selected Hosted UI, choosing our identity provider over the cognito user pool. Finally, we're using Authorization code grant. Maybe we're saying the same thing. When we log in via the hosted UI we get directed to OKTA for sign in. Everything works as expected. We're able to get the user information from OKTA, and Cognito creates a local version of that user that includes the OKTA client id: new-xx-xx_00uat837xx
Cognito also creates a group using a naming convention that includes the aws zone, a random number, and the name of our local identity provider.
The mapping is set from custom:UserType to groups. I'm assuming the Cognito Custom Attribute doesn't have to match the groups attribute name exactly? Its ok to map custom:UserType -> groups rather than custom:groups -> groups? Read/Write permissions are set up accordingly as well.
If these are correct, this is how Cognito was set up it before I messaged you. Okta claims their end is set up correctly. Any other advice?
Thank
@Marcus DeManly , thank you for your comment. Yes,
custom:UserType -> groupsmapping should be fine. The name of custom attribute does not matter here.However, in the ID token the
cognito:groupsattribute will only contain the group names in Cognito side. It will NOT contain Okta side group information. It is not possible to add Okta side groups tocognito:groupsattribute. However, thecustom:UserTypeattribute should be present in the token if you have followed all the steps I mentioned above and this claim will contain Okta side group information. Your application code need to rely on thecustom:UserTypeclaim in ID token for checking the Okta side group names of the user.Currently there is no native feature in Cognito service to sync Identity Provider side groups in Cognito User Pool.