Section |
---|
Column |
---|
| When a user logs in, the SP will send |
|
...
a SAML 2.0 authentication request |
|
...
(AuthnRequest) to SURFconext. Below you will find detail information about the supported bindings, the signing and the available options. Supported bindingsSURFconext supports two types of |
|
...
bindings: - urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect (preferred in accordance to SAML2int profile)
- urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST (
|
|
...
- can only be used in case your software doesn't support HTTP-Redirect)
SigningBy default, the signature on AuthnRequests is ignored. Some |
|
...
use cases and features require AuthnRequest however to be signed. Contact SURFconext support to enable this. |
|
...
- Currently SHA256 signing is supported:
|
|
...
...
...
...
- The SP must provide the public RSA key required for verification of the signature out of band, preferably using SAML metadata.
- The key must be provided an X.509 certificate in PEM format.
- Certificates should be self signed and valid (= not expired).
- SURFconext
|
|
...
...
- only the public key from the certificate. No other validation is done.
- The public modulus of the RSA key must be 2048 or 4096 bits.
- SURFconext can register two trusted certificates per SP.
Authentication request options |
|
...
You can use the following options in AuthnRequest: AssertionConsumerServiceIndexThis |
|
...
method is not allowed in the saml2int profile (see above). Use AssertionConsumerServiceURL instead. AssertionConsumerServiceURLThis attribute is used to specify an alternate AssertionConesumerService Location for the resulting SAML response. This can be any location from the SP metadata registered in SURFconext. When signature verification of AuthnRequest is enabled, the SP is allowed to request any AssertionConesumerService Location. If no AssertionConsumerService is specified, SURFconext will use the default |
|
...
from the SP metadata registered in SURFconext. ForceAuthn |
|
...
With the ForceAuthn parameter you can disable single sign-on. If a user |
|
...
is already logged in and he tries to log in for another service at SURFconext, |
|
...
he will have to authenticate again at |
|
...
...
To force a user to login again at his home IP, both |
Warning |
---|
To disable single sign-on both AuthnRequests must be signed: (1) the AuthnRequest from | the SURFconext and the SURFconext and (2) the resulting AuthnRequest from SURFconext to the home IP | must be signed. Signing prevents a user to remove the force logon requirement by modifying the AuthnRequest. Signing is supported by SURFconext, but is disabled in the default configuration. Note that cooperation of the affected home IPs is required as well to enable validation . By default signing is disabled: contact SURFconext support to enable it. SURFconext can also contact the home IPs involved: they must enable signing of AuthnRequests on their | end. [deze alinea begrijp ik niet helemaal]Contact SURFconext support if you require strict adherence to the ForceAuthn parameter. [wat is dat?] They can enable verification and signing of AuthnRequest by SURFconext, and can contact the home IPs involved. |
IsPassive
...
side. IsPassivePartially supported. When receiving an authnrequest with an IsPassive flag, SURFconext will, in accordance with the SAML specification: - Return NoPasssive if a WAYF would have been presented (multiple IdPs whitelisted for SP and no IdP preselected in AuthnRequest or SSOLocation), else,
- Return NoPassive if the IdP returned a NoPassive response,
- Return an assertion if the IdP returned an assertion.
Support is partial in the sense that currently no response is returned to an IsPassive flag when authentication is stopped at SURFconext because the user needs to give consent, a SURFconext authorization rule forbids login, or second factor authentication for the user is required by SURFconext. For these cases, SURFconext will not return a response, also not an IsPassive response; the flow stops. NameIDPolicyAllowCreateThe value of AllowCreate is ignored. |
|
...
...
format attribute in the NameIDPolicy |
|
...
- A default NameID format. If no format is requested in the NameIDPolicy - Format element in an AuthnRequest this is the format that will be used
- A list of allowed NameIDFormats. If a format is requested in the NameIDPolicy - Format element and this format is in the list of allowed NameIDFormats for the SP the requested format is used. Otherwise the default format is used.
...
parameter: - If specified and if the format is in the list of allowed NameIDFormats it will be used. Otherwise the default NameID format (urn:oasis:names:tc:SAML:2.0:nameid-format:transient only) will be used.
|
|
RequestedAuthnContext
...
- If not specified, the default format will be used.
RequestedAuthnContextIf it contains a single value with a known SURFsecureID LoA, Engineblock will ensure the user authenticates with this or a higher SURFsecureID LoA and return the attained LoA identifier. See Requesting SURFsecureID in authentication requests. On request we can enable it to be transparent, and any value set will be transparently copied to the Identity Provider who may or may not act on it. If not, or any other value is requested, it is ignored.ScopingThis element is used |
|
...
to restrict the IdPs available though a proxying IdP (like SURFconext). |
|
...
SURFconext supports use of the RequesterID element and the IDPList element only. Other elements are not supported.
RequesterID
...
The only elements supported are RequesterID and IDPList: RequesterIDThis element can be used for a SP performing authentication on behalf of another SP ( |
|
...
...
...
contains the EnityID of a SP. This EntityID must be registered |
|
...
at SURFconext and meet all requirements for a SP, except the SAML endpoint information (e.g. AssertionConsumerService Location). |
|
...
The IdPs available are restricted to the ones that have access to both SPs. For a SP to be |
|
...
in that selection rely it needs to ensure that a malicious user can not circumvent the restriction by modifying the AuthnRequest |
|
...
, which can be done in two ways |
|
...
: - Signing the AuthnRequest and requesting SURFconext to enable signature validation for the proxying SP.
|
|
...
...
- EntityID in the AuthenticatingAuthority element in the AuthnContext in the SAML Assertion is
|
|
...
- from an IdP that is allowed access. For
|
|
...
- a list with EntityIDs of the IdPs that are allowed access to your SP
|
|
...
...
...
...
IdPs shown in the SURFconext WAYF. It contains one or more IDPEntry elements with the entityID of the IdP in the ProviderID attribute. The entiyIDs of the available IdPs can be found in the IdPs metadata. If IDPList contains only one IdP, the WAYF will be skipped and the user will be directed to that IdP |
|
...
. Note that there is no guarantee that the user will actually be authenticated by one of the IdPs in the IDPList. The IdP used to authenticate the user can be found in the AuthenticatingAuthority element in the AuthnContext in the SAML Assertion. Code Block |
---|
title | An SAML AuthenRequest using Scoping with an IDPList |
---|
collapse | true |
---|
| <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_123456789097da188e1e4016be09fb13c422553cea" Version="2.0"
IssueInstant="2015-02-25T14:13:02Z"
Destination="https://engine.surfconext.nl/authentication/idp/single-sign-on"
AssertionConsumerServiceURL="https://profile.surfconext.nl/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
<saml:Issuer>https://profile.surfconext.nl/simplesaml/module.php/saml/sp/metadata.php/default-sp</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true"/>
<samlp:Scoping>
<samlp:IDPList>
<samlp:IDPEntry ProviderID="https://idp.surfnet.nl"/>
<samlp:IDPEntry ProviderID="http://authentigate.surfmarket.nl/adfs/services/trust"/>
</samlp:IDPList>
</samlp:Scoping>
</samlp:AuthnRequest> |
|
|
...
scoping When a SP cannot support scoping, also the |
|
...
...
...
...
having its own WAYF or discovery service (Dutch |
|
...
Column |
---|
| Navigate Page Tree |
---|
root | SAML reference |
---|
startDepth | 2 |
---|
searchBox | true |
---|
|
|
|