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.