...
Section | Title | Applies to | Implemented |
---|---|---|---|
2.1.3 | errorURL | Identity Providers (IdPs) | X June 2025 |
2.1.6 | SAML certificates (signing) | Identity Providers | X June 2025 |
3.1.4 | SAML certificates (encryption) | Service Providers (SPs) | X June 2025 |
3.1.6 | RequestedAttributes | Service Providers | X June 2025 |
Section 2.1.3 – errorURL
Implemented: X June 2025
Description
The errorURL
is a metadata element in an Identity Provider (IdP) configuration that points to a web page intended to help users troubleshoot login problems. When a user encounters an issue during authentication, a Relying Party (e.g. a Service Provider) may redirect the user to this URL for guidance or support. Including a valid and accessible errorURL
enhances the user experience and aligns with SAML best practices.
Requirement
An Identity Provider Requirement:
An Identity Provider MUST include an errorURL
element in its metadata.
...
IdPs SHOULD follow the SAML V2.0 Metadata Deployment Profile for errorURL.
Examples
Example not supporting Metadata Deployment Profile for errorURL
Code Block |
---|
<md:IDPSSODescriptor errorURL="https://example.com/error.html"> |
Example supporting Metadata Deployment Profile for errorURL, with the required and optional placeholders
Code Block |
---|
<md:IDPSSODescriptor errorURL="https://example.com/ERRORURL_CODE?ts=ERRORURL_TS&rp=ERRORURL_RP&tid=ERRORURL_TID&ctx=ERRORURL_CTX"> |
Action
:Ensure your IdP metadata contains a reachable reachable errorURL
.
Generic errorURL
A generic errorURL generic errorURL is provided by Skolfederation as an example. More info <here>(länka till en sida som beskriver den)
Section 2.1.6 – SAML certificates (signing)
Implemented: X June 2025Requirement:
Description
A signing certificate is a critical part of an Identity Provider’s SAML metadata. It ensures that SAML assertions and metadata can be cryptographically validated by relying parties. The certificate is included via a <KeyDescriptor>
element, either explicitly marked with use="signing"
or with no use
attribute at all.
Requirement
An Identity Provider Provider MUST include at least one signing certificate.
“A KeyDescriptor element with no
use
attribute or one set tosigning
.”
Examples
Example with use attribute set to signing:
...
Code Block |
---|
<md:KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> <example-certificate-contents> </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> |
Action
:Verify that a valid signing certificate is present in your metadata.
Section 3.1.4 – SAML certificates (encryption)
Implemented: X June 2025Requirement:
Description
An encryption certificate is required in a Service Provider’s SAML metadata to allow Identity Providers to encrypt assertions. This certificate must be included using a <KeyDescriptor>
element, either explicitly marked with use="encryption"
or with no use
attribute (which implies general-purpose use, including encryption).
Requirement
A Service Provider MUST include at least one encryption certificate.
“A KeyDescriptor element with no
use
attribute or one set toencryption
.”
Examples
Example with use attribute set to encryption:
...
Code Block |
---|
<md:KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> <example-certificate-contents> </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> |
Action
:Ensure your SP metadata includes a valid encryption certificate.
Section 3.1.6 – Requested Attributes (SP)
Implemented: X May June 2025
Requirement
...
...
A Service Provider MUST include at least one AttributeConsumingService
element.
Each AttributeConsumingService
...
MUST contain:
A
ServiceName
...
element with an
xml:lang
...
attribute.
A
ServiceDescription
...
element with an
xml:lang
...
attribute.
At least one
RequestedAttribute
.
Each RequestedAttribute
...
MUST include:
A
Name
...
attribute
...
.
...
A
FriendlyName
attribute.A
NameFormat
attribute set to
urn:oasis:names:tc:SAML:2.0:attrname-format:uri
...
Example:
...
.
It is strongly recommended to use attribute from the federation’s attribute profile for interoperability purposes.
If an attribute from the attribute profile is used, the FriendlyName
MUST exactly match the name defined in the profile.
Examples
Code Block |
---|
<AttributeConsumingService index="1"> <ServiceName xml:lang="en">Demo Service</ServiceName> <ServiceDescription xml:lang="en">Used for testing login functionality</ServiceDescription> <RequestedAttribute Name="urn:oid:1.2.752.29.4.13" FriendlyName="norEduPersonNIN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" /> </AttributeConsumingService> |
Action
Add : Add RequestedAttribute
definitions that match the federation profile. Remember to use xml:lang
for language tagging.
...