SAML 2.0 migration guide
As the world of digital identity is constantly evolving, we wanted to provide an even better experience for our customers using the Signicat Identity Broker. That's why we built our new Digital Trust Platform.
The new platform is designed to simplify how you integrate and how you can use other Signicat products, while providing secure, reliable and developer-friendly services to meet your digital identity goals.
On this page, you can find information about the differences between the two platforms when implementing SAML 2.0 connections. In the new platform, you can create and setup connections similarly to how you used to but a few aspects have changed. Learn more about these upgrades below.
For an introduction to the differences between the two platforms, we recommend you start with our Migrating to the new platform guide.
How it works
In the new platform, referred to as the Signicat Dashboard, you can manage end-user login and authentication through the eID and Wallet Hub. This product gives you access to a hub of European eIDs through a single point of integration which supports a range of authentication protocols, such as SAML 2.0 and OIDC.
After the migration, you might want to discover how the new Signicat Dashboard works. To get started, consider the following guides:
Migrating to the eID and Wallet Hub
When you migrate from the Signicat Identity Broker to the eID and Wallet Hub, all your existing connections have already been automatically migrated and are ready to use. We refer to these connections as legacy connections.
To manage your previous SAML 2.0 connections that have been migrated to the Signicat Dashboard, go to Signicat Dashboard > Products > eID and Wallet Hub > Legacy > Legacy connections.
Note that you can also create new SAML 2.0 connections in the new Signicat Dashboard. The difference between new and legacy connections is that legacy connections still support legacy options to provide you with an environment similar to the Signicat Identity Broker. You can learn more about these changes in the next section below.
What's changed
When implementing a connection with SAML 2.0 in the new platform, note that the following properties have changed:
You can find more information about these changes below.
SAML Metadata
We have changed two feature of the SAML Metadata, namely:
- The Metadata URL
- The
IDPSSODescriptorendpoints
New Metadata URL
Our new platform introduces a new Metadata URL path:
You can still use the old metadata URL in the early stages of migration. This is fully supported. However, we recommend you update your applications to use the new Metadata URL.
IDPSSODescriptor
The new Metadata URL endpoint affects the endpoints in the Location attribute of the IDPSSODescriptor object:
- New SAML Metadata
- Old SAML Metadata
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<!-- Artifact resolution endpoint -->
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/ars"
index="0"
isDefault="true"/>
<!-- Single Log-Out endpoints -->
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/logout"/>
<!-- Single Sign-On endpoints -->
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/login"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/login"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://*YOUR_SIGNICAT_DOMAIN*/auth/saml/login"/>
</md:IDPSSODescriptor>
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<!-- Artifact resolution endpoint -->
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/ars"
index="0"
isDefault="true"/>
<!-- Single Log-Out endpoints -->
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/logout"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/logout"/>
<!-- Single Sign-On endpoints -->
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/login"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/login"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://*YOUR_SIGNICAT_DOMAIN*/broker/sp/saml/login"/>
</md:IDPSSODescriptor>
Subject and NameID
You can learn more about the subject in the Concepts > Subject page.
In the Signicat Identity Broker, you used to receive the subject attribute through NameID according to SAML 2.0 specifications. This attribute contained the raw/unhashed subject by default.
In the new Signicat eID and Wallet Hub, this has changed so that NameID returns the hashed subject in the SAML response instead. In your legacy connection you can revert this and receive the raw/unhashed subject instead.
You can view examples of how this has changed, below:
- DigiD
- eHerkenning
- iDIN
When end-users authenticated with DigiD in the Signicat Identity Broker, you used to receive the raw subject (for example, the BSN 900026236) in the response:
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
900026236
</saml2:NameID>
</saml2:Subject>
After migrating to the Signicat eID and Wallet Hub, NameID provides the hashed subject:
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
</saml2:NameID>
</saml2:Subject>
To learn more about the data you can obtain with DigiD, see the DigiD Attributes reference.
How to receive the raw subject
If you prefer to still receive the raw/unhashed subject after the migration, you can choose to either:
- Configure the raw subject for
NameID - Request
idpId
Find out more about each option below.
Configure the raw subject for NameID
Note that you can configure the unhashed subject through NameID only for legacy connections, which have been migrated from the Signicat Identity Broker to the eID and Wallet Hub. This option is not available for new connections.
To configure your SAML 2.0 legacy connection to still return the unhashed subject through NameID, do the following:
- Log in to the Signicat Dashboard.
- Navigate to Products > eID and Wallet Hub > Legacy > Legacy connections.
- Select the SAML 2.0 legacy connection you intend to edit.
- In the connection page, navigate to the Advanced tab.
- In the Advanced tab, tick
Send unhashed subject in the response. - Click Save at the bottom to save the changes.
If the Send unhashed subject in the response checkbox is not available in your SAML 2.0 legacy connection configuration in the Signicat Dashboard, contact us by creating a support ticket in the Signicat Dashboard.
Request idpId
To receive the raw/unhashed subject in the response, you can request it as an additional attribute by specifying the idpId field in the RequestedAttribute element of your SAML authentication request. For more details, see the SAML Request Attributes guide.
When requesting the idpId field, you receive the unhashed subject in the AttributeStatement element in the response. This applies for both legacy and new SAML 2.0 connections.
- DigiD
- eHerkenning
- iDIN
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
</saml2:NameID>
</saml2:Subject>
...
<saml2:AttributeStatement>
<saml2:Attribute Name="idpId">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">
900026236
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
ninWith DigiD you can receive the raw subject (BSN) also when requesting the nin attribute. Learn more about the data you can obtain with DigiD in the Attributes reference.
Attribute naming
The new platform introduces new naming for all the attributes. The new names are shorter, more intuitive and ensure consistency across eIDs. This means that you need to update how you define personal data fields in your authentication request.
Attribute name changes
Expand the sections below to reveal the respective table for each eID:
iDIN attribute name changes (Click to expand)
eHerkenning attribute name changes (Click to expand)
Use legacy attribute naming for iDIN, eHerkenning and DigiD
This option applies only to attributes in the response object. This means that you need to use the new attribute names in the authentication request.
In the eID and Wallet Hub, you can configure your legacy SAML connection to return attributes with the legacy naming in the response, as you used to receive them in the Signicat Identity Broker. For example, this option allows you to receive urn:nl:bvn:bankid:1.0:consumer.bin instead of bin from authentications with iDIN. This means that you receive data points that follow the original naming instead of the new attribute names.
To enable legacy attribute naming in your legacy connections, do the following:
- Log in to the Signicat Dashboard.
- Navigate to Products > eID and Wallet Hub > Legacy > Legacy connections.
- Select the SAML 2.0 legacy connection you intend to edit.
- In the connection page, navigate to the Advanced tab.
- In the Advanced tab, tick
Use legacy attribute naming for iDIN, eHerkenning and DigiD. - Click Save at the bottom to save the changes.
If you enable the Use legacy attribute naming for iDIN, eHerkenning and DigiD for your connection to DigiD and request nin, the authentication response will only contain legacy attribute. Therefore, nin is not provided in the response object since it is a new attribute introduced in the eID and Wallet Hub.
However, you can still receive the BSN (what nin returns) through a separate attribute like idpId.
If the Use legacy attribute naming for iDIN, eHerkenning and DigiD checkbox is not available in your SAML 2.0 connection configuration in the Signicat Dashboard, contact us by creating a support ticket in the Signicat Dashboard.
Example responses
Below, you can find examples of responses from different eIDs with comparisons between the responses you used to obtain from Signicat Identity Broker and the new responses in the Signicat eID and Wallet Hub.
Signicat Identity Broker
- DigiD
- eHerkenning
- iDIN
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://*SP_CLIENT_DOMAIN*/saml/acs"
ID="_704d9e4516572a0286c20f606bf9d817"
InResponseTo="_0929d0af9d4c687ba8991d37e9ae914b"
IssueInstant="2026-01-22T13:56:35.848Z"
Version="2.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://*YOUR_SIGNICAT_DOMAIN*/auth/saml
</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_e9f338a5f71f9893503e2f5e6397952c"
IssueInstant="2026-01-22T13:56:35.863Z" Version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer>https://*YOUR_SIGNICAT_DOMAIN*/auth/saml</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="https://was-preprod1.digid.nl/saml/idp/metadata">
900234854
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_0929d0af9d4c687ba8991d37e9ae914b"
NotOnOrAfter="2026-01-22T13:58:35.863Z"
Recipient="https://*SP_CLIENT_DOMAIN*/saml/acs"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2026-01-22T13:56:30.863Z" NotOnOrAfter="2026-01-22T13:58:35.863Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://*SP_CLIENT_DOMAIN*/saml</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="idpId">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">
900234854
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2026-01-22T13:56:35.866Z"
SessionIndex="e0257917-2439-42fb-8d55-9cf6495d0f6b">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml2:AuthnContextClassRef>
<saml2:AuthenticatingAuthority>https://was-preprod1.digid.nl/saml/idp/metadata
</saml2:AuthenticatingAuthority>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>
Signicat eID and Wallet Hub
- DigiD
- eHerkenning
- iDIN
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://*SP_CLIENT_DOMAIN*/saml/acs"
ID="_53916a1d2da07c83192bc0515d780ba2"
InResponseTo="_119ee07629f26227cdf26ba0f3b4e648"
IssueInstant="2026-01-22T14:15:48.004Z"
Version="2.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
https://*YOUR_SIGNICAT_DOMAIN*/auth/saml
</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_cdcce8081549f709e0e508cd6ea2fbe5"
IssueInstant="2026-01-22T14:15:48.017Z"
Version="2.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>
<saml2:Issuer>https://*YOUR_SIGNICAT_DOMAIN*/auth/saml</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="https://was-preprod1.digid.nl/saml/idp/metadata">
s0VCNNq9aysShPBhbD1LnyHTmtuK9v789e6ST1sD-Pc=
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_119ee07629f26227cdf26ba0f3b4e648"
NotOnOrAfter="2026-01-22T14:17:48.017Z"
Recipient="https://*SP_CLIENT_DOMAIN*/saml/acs"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2026-01-22T14:15:43.017Z"
NotOnOrAfter="2026-01-22T14:17:48.017Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://*SP_CLIENT_DOMAIN*/saml</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="idpId">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string">
900234854
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2026-01-22T14:15:48.018Z"
SessionIndex="eb4f9425-cac9-4177-a600-38f0f989202e">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
<saml2:AuthenticatingAuthority>https://was-preprod1.digid.nl/saml/idp/metadata</saml2:AuthenticatingAuthority>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</saml2p:Response>