Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

SectionTitleApplies toImplemented
2.1.3errorURLIdentity Providers (IdPs)X June 2025
2.1.6SAML certificates (signing)Identity ProvidersX June 2025
3.1.4SAML certificates (encryption)Service Providers (SPs)X June 2025
3.1.6RequestedAttributesService ProvidersX June 2025

Section 2.1.3 – errorURL

Implemented: X 16 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 and fallback. More info <here>(länka till en sida som beskriver den)info here.

Section 2.1.6 – SAML certificates (signing)

Implemented: X  16 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 to signing.”

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:16 June 2025

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 to encryption.”

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 16 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 MUST include:


  • A Name

    from the

    attribute

    profile

    .

  • FriendlyName matching the same profile
  • A FriendlyName attribute.

  • NameFormat =

    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.

...