Amazon WorkSpaces SAML Authentication with Active Directory Federation Service (ADFS)

It appears you're encountering some challenges with configuring SAML 2.0 authentication for Amazon WorkSpaces using Active Directory Federation Services (ADFS). Let's address the issues you're facing:

1. User Access URL Configuration: The error you encountered when using the full URL generated by the script suggests that the format might not be exactly what WorkSpaces expects. The correct format for the relay state URL should be:

https://relay-state-region-endpoint/sso-idp?registrationCode=registration-code

In your case, it should look something like: https://workspaces.euc-sso.ap-southeast-1.aws.amazon.com/sso-idp?registrationCode=wssin+CWJ5CT

This URL should be set as the relay state in your ADFS configuration, not as the User Access URL in WorkSpaces.

2. ADFS Configuration: In your ADFS setup, you need to configure the relay state to point to the WorkSpaces Pool directory relay state URL. This is different from the User Access URL in WorkSpaces.

3. IAM Role Configuration: Ensure that your IAM role for SAML 2.0 federation has the necessary permissions, including the sts:TagSession permission in the trust policy. This is required for certificate-based authentication, which may be part of your setup.

4. SAML Assertion Configuration: Make sure your SAML assertion is correctly configured with the required attributes, particularly the userPrincipalName and ObjectSid (if you're using strong mapping to Active Directory users).

5. Redirection Issue: The fact that you're being redirected to the AWS console instead of WorkSpaces suggests that there might be an issue with how the SAML assertion is being processed or how the relay state is being handled. Double-check your ADFS configuration to ensure it's correctly set up for WorkSpaces and not just general AWS console access.

6. Testing: When testing, use the IdP-initiated flow by accessing the ADFS URL directly, as you mentioned. This should ideally take you through the authentication process and land you on the WorkSpaces page.

Given the complexity of SAML 2.0 integration with WorkSpaces, it might be helpful to review your entire configuration, ensuring all components (ADFS, IAM, WorkSpaces directory, and SAML assertions) are correctly set up. If issues persist, you may need to engage AWS support for more detailed troubleshooting specific to your environment.
Sources
Configure SAML 2.0 and create a WorkSpaces Pools directory - Amazon WorkSpaces
Certificate-based authentication and WorkSpaces Personal - Amazon WorkSpaces
Overview of Active Directory Domains - Amazon WorkSpaces

Side note.

ADFS servers do NOT need to be public facing as they are client side. So long as the end user can access the ADFS server it can be private. If your using ADFS then you must already be connected to a private network and using traditional Active Directory.

Zachary isn't the only one who's running into this same issue. "Invalid parameters. Parameters passed to perform the SAML 2.0 Identity Provider operation are not valid." - this is the error the AWS Console spits out when the "User Access URL" field in the Pools Directory "SAML 2.0 Identity Provider" section of the authentication settings is fed the URI generated in Step 4 of the SAML Implementation Guide. https://d1.awsstatic.com/whitepapers/workspaces/workspaces-saml-implementation-guide_2022.pdf

The issue here seems to be that the SAML 2.0 Identity Provider only accepts URLs up to 213 characters.

**ADFS Configuration: In your ADFS setup, you need to configure the relay state to point to the WorkSpaces Pool directory relay state URL. This is different from the User Access URL in WorkSpaces.**

Can you point out where in the implementation guide this is done? I have followed the implementation guide twice already, thinking I had made a mistake somewhere in the middle only to end up at the same place both times: Successful SAML 2.0 logon to the AWS Console, not Workspaces.

Any assistance here is appreciated, because otherwise we're dead in the water for our Workspaces project.

Update:

This isn't the perfect solution, but at least it works:

https://my.domain.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3durn%253aamazon%253awebservices

The user is brought to a Console session to pick the role they are assigned to, and only then Workspaces manages to log them in. But it's better than the alternative from before.

Did you solve this problem? I have the same problem.

Hi, I am the same Zachary who posted this question (Lost access to my account because it is linked to my previous organization).

No, I did not manage to solve this issue. I gave up on ADFS altogether and used other SAML authentication solutions.