KNF:Korte uitleg SAML protocol/en: verschil tussen versies
(Een tussenliggende versie door dezelfde gebruiker niet weergegeven) | |||
Regel 32: | Regel 32: | ||
Several profiles are defined within the SAML specification, each supporting a different use case. In the context of Entree Federation we'll focus on the '''Web browser SSO profile'''. |
Several profiles are defined within the SAML specification, each supporting a different use case. In the context of Entree Federation we'll focus on the '''Web browser SSO profile'''. |
||
− | + | In this case the user wants to access the protected website of the Service Provider. In order to make an authorisation decision the Service Provider needs to establish the identity of the user. Therefore the Service Provider requests the Identity Provider for an assertion about the identity of the user. Based on the response of the Identity Provider the Service Provider will decide whether or not the user is granted access to the website. |
|
==Authentication process== |
==Authentication process== |
Huidige versie van 11 dec 2016 om 15:44
Nederlands | English |
Entree Federation's main underlying principle is Single Sign On (SSO). A user only needs to log in once at his schoolapplication (Identity Provider) and has automatocally access to all the connected services (Service Providers).
The communication between Service Providers and Identity Providers goes through the central hub of Kennisnet. This way a Service Provider (SP) or a Identity Provider (IdP) only needs to maintain one connection with the central hub. The application of Kennisnet fulfills the role of Identity Provider for all the connected Service Providers and at the same time the role of Service Provider towards all the connected Identity Providers.
Single Sign On is possible because all the different applications communicate on the basis of the SAML 2.0 protocol with each other. SAML means Security Assertion Markup Language. It is an open standard for the exchange of authentication and autorisation data. The standard has been developed and maintained by the non-profit consortiunm OASIS.
Metadata
The different parties within Entree Federation have established a trust relation with each other. They agreed upon several conventions concerning a unique identifier, the role of each party, endpoints and information about encryption. All this is laid down in a metadata file.
This is a simplified example of a metadata file of a Service Provider:
<EntityDescriptor entityID="https://example.com">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor>
...
</KeyDescriptor>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://example.com/sso" index="0"/>
</SPSSODescriptor>
</EntityDescriptor>
- The required attribute entityID contains a unique identifier for the application, preferably in a URL format.
- The element <SPSSODescriptor> describes the role of the Service Provider. In case of an Identity Provider <IDPSSODescriptor> is used.
- The attribute protocolSupportEnumeration contains the supported protocols.
- <KeyDescriptor> includes information about the encryption.
- The <AssertionConsumerService> contains the endpoint an Identity Provider can use to send messages to the Service Provider, in this example an HTTP-POST binding has to be used.
Web Browser SSO profile
Several profiles are defined within the SAML specification, each supporting a different use case. In the context of Entree Federation we'll focus on the Web browser SSO profile.
In this case the user wants to access the protected website of the Service Provider. In order to make an authorisation decision the Service Provider needs to establish the identity of the user. Therefore the Service Provider requests the Identity Provider for an assertion about the identity of the user. Based on the response of the Identity Provider the Service Provider will decide whether or not the user is granted access to the website.