|Note: SAML 1.1 will be deprecated soon. If you are working on a new integration, we strongly recommend that you use OIDC instead.|
A service provider (the Customer) relies on Signicat AS, as the identity provider, to identify the end-user. At the end-users request, the identity provider passes a SAML assertion to the service provider. On the basis of this assertion, the service provider makes an access control decision. We call this SAML assertion the SAML response.
The SAML response is created in both the authentication and the signing scenario. Both scenarios contains two url redirections:
- Before authentication/signature, the user is redirected from the service provider to Id.Signicat
- After authentication/signature, Id.Signicat redirects the user back to the target url, normally to a webpage in the service provider. This redirect includes the SAML response, which contains the end-users identify “package”.
The SAML response generated by Id.Signicat confirms to the SAML specification version 1.1. The specification for SAML can be found at http://www.oasis-open.org/specs/index.php#samlv1.1 (external link). This document also summarizes the security aspects of the SAML protocol.
SAML responses from authentication transactions are always signed with the Signicat’s signing certificate. Such signing is both necessary and mandatory. The purpose is to control integrity and origin of the SAML response, and to prevent tampering with the SAML response.
Signicat’s opinion is that signed SAML responses will improve the security also in the document signing scenario. SAML responses may be stored in the web applications database, and if they are signed, it is always possible to control their integrity and origin at any time later.
The SAML Response contains an SAML Assertion. The assertion contains two statements; an authentication statement and an attribute statement. Each of these has a subject and some information. The subject will always be identical for all statements in the same SAML assertion.
The “subject” in contains a NameIdentifier. This is the information used by the identity solution to identify the user. This will be different for each identity solution. Norwegian BankID use what they call “PID” which is a unique, BankID specific identifier for the user. Swedish BankID use “personnummer”.
The NameIdentifier will always identify the user in a unique manner.
The authentication statement
The authentication statement tells when and how the user was authenticated. The AuthenticationMethod attribute has a unique value for each identity solution.
|Identity solution||Attribute value|
The attribute statement The attribute statement holds additional attributes which we hold to be true about the user. The information is normally collected in the authentication process, but it may also be other information collected by some other means. Each attribute has a name and a namespace. The namespace tells how the attribute information was collected.
We may define custom attribute names if you want standard attribute names across different identity solutions. You may, for instance, want the users name to be present in an attribute with a standard name regardless of how the user did authenticate himself.
An SAML Response may also be downloaded if the user has signed a digital document. The SAML Response is identical, but will also contain the Base64 encoded signed document as an attribute.