SAML SSO for Mattermost using FusionAuth

robotdan

Ok, this is helpful.

<samlp:NameIDPolicy AllowCreate="true" Format="" />

Next step is to identify if this is a valid value according to SAML, if so we need to handle it. Or if it is not, you'll have to see what you can do in your Mattermost config to ensure a value is sent, or omitted.

We can do a little investigation on our end to see if the SAML spec says that Format="" is an acceptable value. My previous understanding was that NameIDPolicy is optional, and if there is not a requested format, the element should be omitted from the document.

dan

Here's part of section 3.4.1.1 of the SAML 2.0 Core spec:

Format [Optional]
Specifies the URI reference corresponding to a name identifier format defined in this or another specification (see Section 8.3 for examples). The additional value of urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted is defined specifically for use within this attribute to indicate a request that the resulting identifier be encrypted

Section 8.3 doesn't show any examples of blank identifiers, and just before section 3.4.1.2, the type of format is specified:

<attribute name="Format" type="anyURI" use="optional"/>

I don't believe an empty string is a valid URI.

I'd probably file an issue with Mattermark and see what they think, if you haven't yet, @misterjoj .

misterjoj

@dan

I have opened a ticket on Mattermost and provided them with the URL to this post. They are looking into it. Thanks for the insights. Will update if there is a way around this.

Best Regards,

robotdan

Great! Let us know what you find out.

dan

@misterjoj do you mind dropping a link (if you filed an issue in a public issue list)? I'd like to follow along if possible.

misterjoj

Hello Guys,

Finally here is the feedback from Mattermost:

So one issue that we found is that this incorrect format of the NameIDPolicy is actually part of the go-saml library we're using to create the assertions.
There's been a PR opened in the repository of this library that is supposed to fix this, however we do not necessarily know when this will get merged.
For that reason we'll merge the fix into a fork we maintain until the PR is merged upstream.

Now I have used the old saml implementation with dependency on xmlsec. I hit a blocker there as well and I figure out that there is a step that I can't seem to get around to. If you follow the documentation for okta https://docs.mattermost.com/deployment/sso-saml-okta.html the step 8: Set Assertion Encryption as Encrypted and upload the Service Provider Public Certificate you generated in step 2 to the Encryption Certificate
Same for oneLogin https://docs.mattermost.com/deployment/sso-saml-onelogin.html section 2. b. Paste the Public key that you generated earlier into the SAML Encryption field.

I haven't seem a way to do SAML assertion encryption with fusionauth. Is there a way to do that? With that I am sure I can complete the setup. Thanks in advance

dan

Hiya,

I'm glad you figured this out.

Here's a SAML example where a signing key was created: https://fusionauth.io/docs/v1/tech/samlv2/zendesk

You can either generate one in the "SAML" tab of your application when you are setting it up, or you can go to "Key Master" and create or import one. You can see the private and public key by going to "Settings" and then "Key Master".

Then, in the "SAML" tab of your application you can set the "Signing key" to the value of the key you created.

Hope that helps.

misterjoj

Hey @dan ,

Thanks for your reply. At first, I also thought the certificate being referred to is the same as the one generated but I believe the scenarios are different.

It looks to me that 2 certificates are being used.

1- Service Provider generates a certificate that is imported into the Identity provider for Assertion Encryption. (Step 8 of the okta example )
2 The Identity provider generated certificate that is imported in the service provider (Step 12 of the otka example)

So in FusionAuth SAML section I only know or see Identity provider public certificate being configured. Nothing pops out to me on where to put the service provider certificate along side with its own Identity provided generated one.

I don't know if you get my point.

Thanks

dan

Ah, thanks. I didn't catch that it was happening both ways.

Looks like you can turn off the assertion encryption, though it is not recommended for production: https://docs.mattermost.com/administration/config-settings.html . I'd probably try turning it off just to see if you can get it to work end to end. Then you can make the call if that is a security setting you're willing to live with.

The bad news is that FusionAuth doesn't support "Service Provider Public Certificates" for assertion encryption at this time. Please feel free to file an issue: https://github.com/fusionauth/fusionauth-issues/issues requesting such support (I didn't see anything previously filed).

Here's guidance regarding our roadmap: https://fusionauth.io/community/forum/topic/172/the-fusionauth-roadmap

misterjoj

thanks , I will do just that

Best Regards,