AWS IAM Identity Center SSO

[peakematt]

Describe your question/ I'm working on setting up Authentik as the identity provider for AWS IAM Identity Center (which is the rebranded name for AWS SSO). Neither app officially supports the other, but its just a SAML2 integration. I created the saml provider and app in Authentik and exchanged metadata files between the two apps. Both apps accepted the metadata and AWS redirects to Authentik. Both IdP and SP-initiated flows appear to start correctly. However, when redirected back to AWS, AWS' login screen presents a generic error message: We couldn't complete your request right now. Please try again later. When I look in CloudTrail logs for the corresponding event, I get messages like:

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "Unknown",
        "principalId": "<AWS Account number>",
        "arn": "",
        "accountId": "<AWS Account number>",
        "accessKeyId": ""
    },
    "eventTime": "2023-01-28T17:16:48Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ExternalIdPDirectoryLogin",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "<my ip>",
    "userAgent": "<my user agent>",
    "errorMessage": "Response contains invalid name id policy format",
    "requestParameters": null,
    "responseElements": {
        "ExternalIdPDirectoryLogin": "Failure"
    },
    "requestID": "5d21c791-9132-4ea8-b6b7-5a07db654346",
    "eventID": "c148dedd-9057-4e63-b4ee-44c675f2353b",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "recipientAccountId": "<AWS Account number>",
    "eventCategory": "Management"
}

So - it seems like AWS is unhappy with the NameID being returned by Authentik. Based on AWS' documentation, AWS SSO wants NameID to be an email address. I did go in and update the NameID property mapping value to be the Authentik default email attribute mapping (see screenshot), but that does not seem to help. Auth also did not work with the NameID Property Mapping field left unassigned.

I haven't set up any SCIM functionality so I have to provision AWS IAM Identity Center users manually. I have confirmed that I have a user provisioned in AWS that matches the user information Authentik is asserting.

Any thoughts on what might be causing this? Or ideas on what I might try changing to get it working?

Relevant infos using authentik version 2023.1.2 running from the official (ghcr.io/goauthentik/server:2023.1.2) container. My containers are scheduled by Hashicorp Nomad and HTTP traffic enters via a HAProxy reverse proxy that terminates TLS connections.

Screenshots

Logs Not super relevant? I can provide details if needed, but Authentik shows a successful application authorization and AWS generates errors like above.

Version and Deployment (please complete the following information):

• authentik version: 2023.1.2
• Deployment: Official docker container running in HashiCorp Nomad behind HAproxy.

Additional context None

[StevenMonty]

Having a very similar issue myself, commenting to stay in the loop

[BeryJu]

These settings work for me, no custom NameID property required

[StevenMonty]

@BeryJu Thank you so much, those worked for me! I already had a user provisioned manually with a matching email address, but have you been able to get automatic provisioning working?

[andresdb91]

@StevenMonty I got automatic provisioning working using SCIM by modifying the user and group property mappers to include:

• User:

  • externalId = str(request.user.id)
  • displayName = request.user.name
  • active = request.user.is_active
  • groups = [...] (optional, see below)

• Group:

  • externalId = str(group.group_uuid)
  • members = [...] (optional, see below)

I had to add the last one since users would be deactived by default without it.

To get user-group relationships to work I had to add the groups and members attributes to both user and group mappers following the RFC structure and replacing the .. in the $ref field by the Authentik URL followed by /scim/v2 -> https://authentik.ourdomain/scim/v2. For the values I used the same IDs previously specified as externalId, so user.id for the members and group.group_uuid for the groups in my case. Finally, to iterate groups/members you have to use the ManyToManyField defined in the User model and iterate over the all() method:

for group in request.user.ak_groups.all():
  ...

for member in group.users.all():
  ...

Also for some reason users wouldn't get mapped if they didn't have any custom attributes in them so I put a simple asd: asd field in there.

[BeryJu]

@andresdb91 I just noticed that the displayName and active attributes got lost somehow when I migrated the provider to use mappings instead of having a fixed internal mapping, thanks!

Also FYI, I recommend not setting the externalId in your mapping as the provider sets this by default (https://goauthentik.io/docs/providers/scim/#using-in-conjunction-with-other-providers) and with the default value, the same identifier is used as with SAML and OAuth

Also for groups, you shouldn't have to do anything custom, as authentik will update the group membership when a user is added to/removed from a group

(During development I actually tested the provider mainly on the AWS SSO implementation of SCIM so this all should just work out of the box)

[BeryJu]

We have docs for the AWS Identity Center (or whatever they've renamed it to today) now, so I'll close this issue https://goauthentik.io/integrations/services/aws/#select-your-method

[kuzaxak]

Still reproducible with default settings. Any tips on how to troubleshoot it?

UPD: Works without specifying NameID profile. Do not forget to change Application -> Edit -> Launch URL == AWS access portal URL

[jslay88]

I have followed the docs, gone through it multiple times. SCIM is working fine, users and groups are created, but I cannot seem to actually get any user to sign in. I have made sure the user has been added to AWS accounts with permission sets.

When a user tries to sign in, they are given the error

This also produces no ExtenalIdPDirectoryLogin event in Cloud Trail

Verified Issuer and Audience, verified signing cert is correct in AWS and selected on the Provider in Authentik, I have the Launch URL set to the Access Portal URL, no idea what else to try.

When viewing the request in the browser developer tools, it shows the POST to AWS as 400.

[lanrat]

@jslay88 I had the exact same issue.

The problem was that I had Authentik's AWS SAML & SCIM providers using the username as the Authentik username, where AWS needs the username to be the user's email. This is not well documented and the error message is not helpful at all.

[jslay88]

@jslay88 I had the exact same issue.

The problem was that I had Authentik's AWS SAML & SCIM providers using the username as the Authentik username, where AWS needs the username to be the user's email. This is not well documented and the error message is not helpful at all.

Good find! I am not able to test this until late next week, but I definitely will!

[edw1nzhao]

@jslay88 did you end up figuring this out? I'm running into a similar problem here - I have SCIM working, but unable to login a user.

I'm using the first image's property mapping there in @lanrat 's comment.

[thechubbypanda]

@lanrat do you have a working solution at the moment? I'm running up against the same "code isn't right" error. I've swapped the default SAML username mapping with your suggested one but the problem does not change.

[lanrat]

@lanrat do you have a working solution at the moment? I'm running up against the same "code isn't right" error. I've swapped the default SAML username mapping with your suggested one but the problem does not change.

I used the settings in my screenshots and its been working great.

[thechubbypanda]

@lanrat I have added the SAML mapping from the first photo in a new mapping and then replaced the default authentik default SAML Mapping: Username with it. This does not appear to change anything.

What is the second screenshot? Would you be able to provide a slightly more detailed explanation of what goes where? I feel I may be missing something.