service_list() now returns a list of objects with 3 fields:
- name
- url
- actions
name and url are self-explanatoring, actions is a list of tuples of
length 3 or 4:
- (name, http_method, url, post_content)
It allows to export any action toward a provider given there is an URL
endpoint to do it.
It's needed for SAML2 logout to work; as it's impossible to send
more thant one NameID in the logout request and you never know which
assertion reached the service provider among all the one emitted during
a session.
The userconsent during SSO is about account linking on the IdP side.
In 3.2.1 Complex Type RequestAbstractType of the saml-core-2.0-os specs
Consent [Optional]
Indicates whether or not (and under what conditions) consent has been
obtained from a principal in the sending of this request. See Section 8.4
for some URI references that MAY be used as the value of the Consent
attribute and their associated descriptions. If no Consent value is
provided, the identifier urn:oasis:names:tc:SAML:2.0:consent:unspecified
(see Section 8.4.1) is in effect.
*The Consent attribute is thus not applicable for the SP to ask the user
consent.*
However this attribute is meaningful in the response
In 3.2.2 Complex Type StatusResponseType
Consent [Optional]
Same as above s/request/response.
- The authnrequest Consent attribute is not used anymore.
- A parameter has been added to the idp options policy to indicate
how the service provider must handle the Consent attribute of the
authresponse. If force_user_consent is True, the SP reject the SSO
if the consent attribute in the response is not in the set of
the consentement strings.
- Add a paramater to the attribute policy model to configure the
display of the page per service provider.
- Add support during the SSO process of a hook for asking users
their consent to send attributes and select which attributes.
- Add form to select attributes or refuse to send attributes
Mikaël Ates
Benjamin Dauvergne