SAML 2.0

Seylo supports SAML 2.0 alongside OIDC. Configuration lives under Single sign-on → SAML 2.0, which shows you the SP entity ID and ACS URL to give your identity provider.

Where these values come from

The SP entity ID, the ACS URL and the Destination Seylo validates are all derived from the portal’s configured public base URL — deliberately not from the request’s Host header, which would let a request choose the value it is checked against.

AWS IAM Identity Center

Identity Center is a SAML 2.0 provider for third-party applications; it does not act as a generic OIDC provider for them, so this is the path to use.

1. In Seylo: Single sign-on → SAML 2.0, preset AWS IAM Identity Center. Note the SP entity ID and ACS URL.

2. In Identity Center: Applications → Add application → I have an application I want to set up → SAML 2.0. Upload Seylo’s SP metadata, or paste the entity ID and ACS URL by hand.

3. Attribute mappings:

   Attribute	Value	Format
   Subject	${user:subject}	persistent
   email	${user:email}	basic
   groups	your group attribute	basic

   Identity Center sends no groups by default — the mapping is required.

4. Back in Seylo: import Identity Center’s metadata by URL or paste, confirm the certificate fingerprint with whoever administers it, set the role attribute (https://aws.amazon.com/SAML/Attributes/Role, or your own groups), and map the values.

Active Directory Federation Services

1. AD FS → Relying Party Trusts → Add → Import data about the relying party from a file, using Seylo’s SP metadata.
2. Claim rules:
   • Send LDAP Attributes as Claims: E-Mail-Addresses → E-Mail Address; Token-Groups - Unqualified Names → Role.
   • Transform an Incoming Claim: E-Mail Address → Name ID, format Email.
3. Set the secure hash algorithm to SHA-256. Relying Party Trust → Properties → Advanced. Older Windows Server versions default to SHA-1, and Seylo rejects SHA-1.
4. The role attribute is the WS-* URI http://schemas.microsoft.com/ws/2008/06/identity/claims/role — not roles.

Generic SAML

Import your provider’s metadata (URL or paste) and name the role attribute. If several customer organisations share the identity provider, set a discriminator so the second one registered can be told apart from the first.

What is enforced

XML signature validation uses @node-saml/node-saml rather than hand-rolled XML handling. Two properties are worth stating because they are the ones that get got wrong elsewhere:

• Verification processes the bytes the signature actually covered, not a signature node found in the document. This is what defeats signature-wrapping attacks.
• Validation is only against the certificate you configured. A certificate embedded in the received document is never used.

Common problems

Code	Cause	Fix
saml-not-configured (404)	Wrong slug in the ACS URL, suspended organisation, or no SAML config	All three return one error on purpose, so the endpoint cannot be used to enumerate organisations. Check the ACS URL first
signature-invalid	Unsigned assertion, unsigned response, or an untrusted certificate	Both the response and the assertion must be signed. Re-import the provider metadata after a certificate rollover
Signs in, no permissions	Role attribute not sent or not mapped	AWS and AD FS both need the attribute mapping added explicitly
AD FS rejected	SHA-1 signing	Switch the Relying Party Trust to SHA-256