1 260
szerkesztés
Módosítások
→Advanced SAML2 settings
* time of the registration
=== Advanced SAML2 settings features ===
SAML2 defines several properties of the authentication request message which may affect the authentication performed by the IdP.
{{STOP|'''Be careful when using these options.'''
IdPs that do not support these features might signal an error instead of performing any kind of authentication of the user. Or might show errors ''after'' authenticating the user. Some kind of authentication methods handlers (ie. HTTP Basic Auth) will never work even if the IdP software is capable of handling these properties. }}
==== isPassive ====
If <code>isPassive</code> is set, then the user is redirected to the IdP or to the Discovery Service in advance, but neither of them are allowed to take over the control of the user interface (such as performing any visible authentication). If authentication (or IdP selection) can not be performed silently, an error is returned, which is then handled by the module.
By using this option, you can auto-login users who are already logged in to the IdP even if you are using lazy sessions. If auto-login can not be performed, the user returns to Drupal unauthenticated without seeing any error message.
{{ATTENTION_EN|You need to instruct Shibboleth to redirect errors back to Drupal to handle passive authentication failures. This is done by setting <code>redirectErrors</code> parameter in the RequestMap. See [https://spaces.internet2.edu/display/SHIB2/NativeSPContentSettings Shibboleth wiki] for details. '''TODOIMPORTANT''': current implementation does not handle any errors except for NoPassive error. This means, that on every possible Shibboleth SP error you will get an unauthenticated Drupal page instead of a Shibboleth settingserror page.}}{{NOTE_EN|this feature requires JavaScript.}}
==== forceAuthn ====
This feature requires reauthentication of the user at the IdP even if she is having an SSO session there. Just like isPassive, it's not generally supported by authentication handlers.
In general, you should never mix '''isPassive''' and '''forceAuthn'''. The standard states that in this case, the IdP must reauthenticate the user without visibly taking control of the user interface. It's up to you, how you interpret it...
==== Non-implemented features ====
There are several other SAML features which are not yet implemented, because there seems to be very little practical interest for them. Please file a feature request if you really need them, but before doing so, please, spend a little time on thinking how things should really work.
* '''AuthnContextClass''': the SP can request some specific authentication context from the IdP.
* '''NameID management''': the IdP can request to change the user's NameID (targeted identifier) or to remove it.
* '''Logout notification''': this is a Shibboleth2 feature, not a SAML one. You generally do not need this, because you can terminate the Drupal session on Shibboleth session expiry. This workaround has the disadvantage that the module will not be notified at the time when the user was logged out, only on the next page refresh.
::<small>There is a known security problem of this workaround illustrated with this sequence:
::# User ''Alice'' logs in to Drupal (and to her IdP)
::# Session of ''Alice'' terminates at the SP
::# User ''Bob'' at the same browser logs into the same SP but to another application, thus he has a Shibboleth session
::# User ''Bob'' can access content in Drupal as ''Alice'' (without the roles derived from Alice's attributes) </small>
== Change log ==
