For Service Providers there are normally no changes needed to make use of SURFsecureID. To require SURFsecureID for all logins to a specific Service Provider, or for all logins by one or more IdP's to a specific Service Provider, the SURFconext team can set a configuration option to enforce this.
The following documentation is for special requirements which can not be satisfied with this configration and that require the service to make use of a special SAML endpoint.
This part of the wiki gives all the (technical) information that can be of importance for Service Providers working with SURFconext Strong AuthenticationSURFsecureID.
- To start with it is explained how you can connect your service with the Strong Authentication the SURFsecureID gateway. Actually it is very similar to the 'normal' way of connecting to SURFconext. The are only small differences, like using other metadata. Also you will have to tell the gateway the required Level of assurance (LoA1, LoA2 or LoA3). For an overview of all the differences between SURFconext Strong Authentication between SURFsecureID and the 'normal' SURFconext authentication procedure, have a look on this page.
- Else in the wiki we already described the concept of levels of assurance. Here you will find the (technical) details needed to communicate the strength of authentication between the SURFconext Strong Authentication the SURFsecureID gateway and the Service Provider.
- With SURFconext Strong Authentication With SURFsecureID you have also the possibility to have second factor only authentication. In that case the first factor authentication (username and password) is done at the IdP (and not at SURFconext). We explain the differences between second factor only authentication and the 'normal' authentication. After that the SAML AuthRequest and SAML response for second factor only authentication are explained. Also you can read how to implement second factor only authentication and finally you will find a link to an example.
- To be able to use SURFconext Strong Authentication use SURFsecureID metadata is needed. There are three sets Each of the three environments has two types of metadata: ; one for the Production environment, one for the Test environment and another one for regular SAML endpoint, and the other for the second factor only authenticationendpoint.
- On the next page we give examples of an authentication request at a specific LoA, You will see also two examples of the SAML response in case of an authentication failure.
- You can use SimpleSAMLphp to request a specific minimum level op assurance (LoA) from the Strong Authentication the SURFsecureID gateway and to verify the LoA at which the user is authenticated. For both instances you will find an example.
- If you use Shibboleth as your sign-on system, you can read here how to configure it for SURFconext Strong AuthenticationSURFsecureID.
- For testing your connection to SURFconext Strong Authentication to SURFsecureID you should not use any 'regular' account, but a special Onegini account.