Skip to end of metadata
Go to start of metadata

SAML 1.1 & SAML 2.0


Signicat offers authentication services using either SAML 1.1 or SAML 2.0. If you are using an identity federation service such as Microsoft ADFS or Oracle Identity Federation, then you are most likely interested in Signicat SAML2 gateway.

See the documentation for Signicat's SAML 2.0 interface if that is the case.


Authentication using SAML 1.1


Commonly, the authentication process starts in your application and will consist of the following steps. You are required to carry out the actions marked in bold.

  1. Redirecting the user to Signicat: You are the service provider (SP) and you need to authenticate an end user in order to grant him or her access to some service. In order to do that, you redirect the user to Signicat (in the browser).
  2. Signicat will host the entire authentication process using any of the available (or desired) id methods, after which a SAML assertion (XML) is constructed. The SAML assertion will be signed with a certificate which ensures that the contents of the assertion cannot be spoofed or altered.
  3. Receiving the SAML response: Signicat will then redirect the user back to your application along with the aforementioned SAML assertion.
  4. Verifying the SAML response: Your application will pick up the SAML assertion and validate it to make sure it's correct.
  5. Retrieving attributes from the SAML response: After validation has taken place, the values in the SAML assertion (such as user name, personal identity number etc.) can be extracted and processed by your application for further usage (typically logging the user in).

Redirecting the user to Signicat

The first step of the authentication process is as easy as constructing a URL. The URL will have the following format:

where the red parts will depend on what you want to do:

  • env is the environment. When you're first starting out, this will typically be preprod, and in production it will be id.
  • service is the name of your service as registered with Signicat*. There is a demo preprod service called demo which you may use as you'd like, but eventually you will start using your own service.
  • method is the name of the id-method as registered with Signicat*. Common abbreviations are nbid for Norwegian BankID, sbid for Swedish BankID, nemid for Danish NemID, tupas for Finnish Tupas, esteid for Estonian ID-card and so on.
  • profile is the name of the graphical profile** you would like to use. If you don't have a graphical profile, you can omit the value and the default profile will be used.
  • language is the (ISO 639-1) two letter code for the language you would like in the user interface, such as nb for Norwegian, da for Danish, sv for Swedish, fi for Finnish, et for Estonian and so on.
  • target is the URL-encoded (or "percent encoded") URL to the application which is to receive the SAML assertion. If you're starting out testing the services, then perhaps your URL is http://localhost:8080/auth/verify and if you URL encode that you'll end up with http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fverify. Any parameters you use in any of your URL's should always be URL encoded according to the URL standard, so make sure you adhere to that.

Note that all URL parameters must be properly URL encoded using UTF-8, as per RFC 3986.

* If your company name is Foo then your service name can be "foo", and if you're using Danish NemID then the method name can be "nemid" or something completely different if you'd like. Please contact if you're unsure of the name of your service and/or available id-methods.

** A graphical profile is an HTML template which can be used to wrap the dynamic content served by Signicat. See also How to work with graphical profiles.


Let's put the pieces together and construct a URL where we send the user to the preprod environment, using the demo service, the Danish NemID method, a demo profile, danish language and localhost as the target:

Clicking the link will send you to a page where the NemID applet is loaded and the authentication process starts, such as in the following screenshot:

Receiving the SAML response

After authenticating, Signicat will redirect the user to the target using HTTP POST. In terms of HTTP, this is what the request would like like:

SAML 1.1 POST profile


Host: localhost:8080
Proxy-Connection: keep-alive
Content-Length: 9213
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
SAMLResponse=PFJlc3BvbnNlIHhtbG5zPSJ1c...and so on and so on...Rpb24%2BPC9SZXNwb25zZT4%3D%0D%0A&TARGET=http%3A%2F%2Flocalhost%3A8080%2Fvalidate


Decoding the SAML response will result in the actual SAML (XML) document which contains information about the authentication. Read more about SAML or have a look at example SAML responses for different id providers.


Verifying the SAML response

The SAML response is a signed XML (xml-dsig) and the signature must be verified in order to ensure the correctness of the assertion. Signicat provides libraries that will help you verifying the SAML using Java or C#.

  1. How to verify a SAML response using Java
  2. How to verify a SAML response using C#
  3. Links to the certificate if you use your own integration: SAML certificate

Retrieving attributes from the SAML response

Please refer to this overview of which attributes are available in the SAML responses.