search

subspacecommunity / subspace

A fork of the simple WireGuard VPN server GUI community maintained
MIT License
1.8k stars 131 forks source link

Unable to get SAML with AWS SSO working #131

Closed opub closed 4 years ago

opub commented 4 years ago

Describe the bug When configuring a custom SAML application in AWS SSO you must provide either the SP's SAML metadata file or the combination of the ACS URL and audience. I couldn't find a way to get the SAML SP metadata from Subspace so I tried using the ACS URL and audience. The ACS URL is provided in Subspace but the audience is not.

What value should be used for Audience? Are there any attributes that are required to be mapped for this to work?

Screenshots

Screen Shot 2020-08-14 at 1 18 07 PM

Desktop (please complete the following information):

Additional context I tried putting the entity ID as the Audience and the handshake failed with an error that the ACS URL didn't match. I don't know if that is a side effect of not having the other fields set correctly or something else.

Screen Shot 2020-08-14 at 1 36 49 PM
opub commented 4 years ago

My initial installation had insecure=true because I'd had an issue getting LetsEncrypt to validate. Once I got that fixed I was able to get the metadata XML file from /saml/metadata. That seems to have gotten me passed the error above. The SAML handshake and assertions now look correct. But the /saml/acs page is failing with "Forbidden".

jpbostic commented 4 years ago

Hi @opub - I ran into the same error that you encountered and was able to get past this error after I realized something: every time I make a change in my AWS SSO application settings, the metadata XML file changes, so I have to download it again and replace what I'd previously pasted into subspace's settings idP metadata text box (and remember to click "save"). More specifically, after I'd uploaded the subspace metadata XML file saved from the /saml/metadata URL to AWS SSO, I clicked "Save Changes" and then clicked download on the AWS SSO metadata file (apparently "Save Changes" updates the file). Why it even gives a link to download the metadata file from AWS SSO before saving changes is clicked is beyond me.

By the way, I ran into another login error, "Request nameID format does not match our record". I fixed that by going to the AWS SSO app's "attribute mappings" tab and adding a mapping of: attribute: Subject ... maps to: ${user:email} ... format: emailAddress ... then saving changes and, one more time, download the AWS SSO metadata XML and pasting that to replace that in subspace's settings idP metadata text box (don't forget to click "save").

Good Luck!

opub commented 4 years ago

Thanks @jpbostic. I had figured out the same thing. Everything is working great now.