Question

SAML settings and documentation question

1

After some userlib hassle (see my other post on the sollution, thank you Jaap) it have managed to get SAML started in Mx5. But I still have some questions because the Mx5 SAML module has evolved a bit since the Mx4 SAML module. And simce this module is not on github yet I post a small bug fix here. There is a small bug in the form SSOConfigStep4. The next button does not call the microflow asynchronous. But since this microflow refreshes MxModelreflection that will take more then 30 seconds so you get a timeout. So change this in the form to let this microflow run asynchonous and you are fine. And the save button of the form SSOConfigurationEdit does not have a Dutch translation. Now my problem. In the old module I got redirected to: appurl/openaselect/profiles/saml2/sso/web?SAMLRequest=jVNNj5sALOTOFCHARACTERSw3D&RelayState=null But now when I get redirected to: apprurl/openaselect/profiles/saml2/sso/web This will result in a 403 forbidden and not the SAML login page of the customer. I am missing the SAML request. Now may be I am missing something in the settings and the documentation is not clear about some parts (see the screenshot) The options Force authentication, Passive authentication, Allow Idp Intiated Authentication and Disable NameID policy are not explained in the documentation. I have tried some combinations but have not seen any difference. Maybe that Jaap can give some more explanation about these config options and how I can get the SAML request in the URL redirect. Regards, Ronald [EDIT] Found some more small bugs. AssertionAttribute and SAMLsession have no entity access set so you get a warning when going to production. [EDIT 2] after asnwer from Jasper (to big to comment) Jasper, thank you for the elaborate answer. When I download the IdP Metadata I see a X509 certificate but this certificate I do not see inside the Mendix app. And about certificates, in the old module I noticed that the certificates never had filled in valid from and valid to fields filled out. The problem was that when the customer created new certificates (this was done automaticly a couple of weeks before the old one would expire) all the request would fail because the JAVA code could not hanle multiple certificates. We received an upgrade of the JAVA code that would check the valid from and to fields but since these values never ended up in the database this code would still not work. I tried to find this routine in the JAVA code, but so much has changed that I got lost a bit. Do you know if this bug has been solved? [EDIT 3] I still am having problems with certificates. When I check the metadata.xml I see a 509 certificate. But I do not see this certificate in the certificate section after importing the metadata. What could be the reason that the certificate is not added? [EDIT 4] Here the screeshot after finishing the wizard. When I download the metadata there is a 509 certificate but I do not see it in Mendix. [EDIT5] Here the request settings, As far as I can tell these are ok, unless they are case sensative.

asked 2015-08-20

Ronald Catersels

1 answers

Jasper van der Hoek · Accepted Answer · 2015-08-20

SAML 2.0 knows many different ways to authenticate between the IdP (user management) and the SP (Mendix). You are right that a lot of the SAML configuration isn't documented explicitly in the Mendix module, that is because most options in the configuration are SAML specific options and can be found on the internet. A few examples are passive / forced authentication, or the security context. That is the exact terminology used in SAML and therefore it was chosen not to explain those in detail since it literally enables/disables the respective property.

The change in behavior is due to the more extensive support of SAML. The first version of the SAML module only supported basic HTTP Redirect communication (all information must be passed through url parameters) and not even all options in HTTP Redirect were supported.
Due to the inherent limitations of what you are allowed to communicate in a url the module automatically didn't allow for encryption etc (wiki). (The first version doesn't encrypt any information it only applied base64 url encoding).

The current release is extended to also supports HTTP Post, allowing for larger, more complicated, and more secure exchange of information. By enabling HTTP Post messages we can no also support strong encryption and decryption for every step in the login process.
Because of these advantages the module automatically prefers HTTP Post over Redirect. The reason for choosing Post over Redirect is because with the latter you always have to be aware of the exact requirements of the IdP. If the IdP requests to much information, or requires you to sign or encrypt the requests the login behavior could change between post and redirect every time you login (depending on the size of the info we pass in the url).

For example the IdP Metadata from an Idp could specify the following three options. According to the SAML standard the SP is allowed to pick any of the sign on services to login. HTTP artifact sign on is not supported by the module, and it prefers POST over redirect. In this case because it is allowed to chose any of the three it will always send a post message to the login service. The Service should reply back using the same method.

  <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://inloggen.hogeschoolutrecht.nl/openaselect/profiles/saml2/sso/web"/>
  <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://inloggen.hogeschoolutrecht.nl/openaselect/profiles/saml2/sso/web"/>
  <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://inloggen.hogeschoolutrecht.nl/openaselect/profiles/saml2/sso/web"/>

The 403 problem is likely caused because of the HU refusing your request. The message you are sending to the IdP must be trusted by them, and part of that is that both the IdP and SP know about each others certificates (From the metadata files). Is your SP Metadata file loaded into the IdP as a trusted Service Provider?
Just an FYI, by enabling the ForceAuthentication option you are instructing the IdP always to ask for a username and password, even if there is still an active session on the IdP. If that option is set to false the IdP is allowed to keep a session for (usually 10-20) minutes in which the user won't have to enter their password. When set to true, users must enter their password every time. Active/Passive is a variation on the SAML protocol, where passive solely relies on the information being exchanged through the browser. Active authentication can have soap communication between the IdP and SP too. However in my experience most IdPs and SPs don't do anything with this option though.

We'll change the button to run async,
In regards to the security of AssertionAttribute and SAMLsession, those are entities that should only be used internally by the module. No users should have access to those entities (the only thing you can do with them is break them). That is why no security has been specified on them.