Protocol practice · Federation & Identity Standards

SAML 2.0: sign-in started by the service provider

Objective: You run the company wiki at wiki.example, and Harbor’s employees sign in through Harbor’s identity provider. Sign Rui Okafor in, and refuse the assertion you shouldn’t trust.

About 12 minutes · simulated, no real servers

1Ask the IdP
2Receive the response
3Check assertion A
4Accept assertion B
5Start the session

Where SAML fits

Sign-inWho is this?

OpenID Connectbuilt on OAuthSAMLYou are hereKerberosWindows domains

AccessWhat may this app do?

OAuthaccess for an app

AccountsDoes the account exist?

SCIMjoiners, movers, leavers

Not sure? Which protocol?

SAML at work, every day

Each of these is single sign-on into a company app, through the browser.

Opening the expense tool from the company portalOne click, no second password.
Signing in to an HR system with company credentialsThe identity provider vouches; the app trusts its signature.
An established enterprise appMany offer SAML first, or only SAML.

Step 1 of 5

Send the user to the identity provider

Rui opens the wiki and has no session. Your application builds an authentication request and sends the browser to Harbor’s identity provider with it.

GET https://idp.harbor.example/sso?SAMLRequest=…&RelayState=/pages/onboarding
# SAMLRequest, before it’s compressed and encoded:
<samlp:AuthnRequest ID="______" Version="2.0"
    IssueInstant="2026-10-08T14:01:58Z"
    Destination="https://idp.harbor.example/sso"
    AssertionConsumerServiceURL="______">
  <saml:Issuer>______</saml:Issuer>
</samlp:AuthnRequest>

Fill in the three blanks, then send the user.

ID: how you’ll recognize the answer

AssertionConsumerServiceURL: where the answer comes back

Issuer: who’s asking

Pick an answer for each blank to continue.

This step

Service provider: The application the user wants to use: here, the wiki. It trusts the identity provider to say who the user is.
Identity provider: Signs the user in and vouches for them with a signed assertion. Here, Harbor’s.
Entity ID: The unique name each side is known by, exchanged in metadata before anyone signs in.
AuthnRequest: The service provider’s request to sign a user in. Its ID comes back in the answer.
Assertion consumer service: The service provider’s endpoint that receives responses. Registered in metadata, so the IdP won’t post anywhere else.

Earlier steps (0)

All terms (15)

Service provider: The application the user wants to use: here, the wiki. It trusts the identity provider to say who the user is.
Identity provider: Signs the user in and vouches for them with a signed assertion. Here, Harbor’s.
Entity ID: The unique name each side is known by, exchanged in metadata before anyone signs in.
AuthnRequest: The service provider’s request to sign a user in. Its ID comes back in the answer.
Assertion consumer service: The service provider’s endpoint that receives responses. Registered in metadata, so the IdP won’t post anywhere else.
Binding: How a SAML message travels: redirect, POST, or artifact. In browser sign-in, everything goes through the browser.
RelayState: An opaque value the IdP hands back unchanged, usually where the user was going. Check it before you follow it.
Assertion: The signed statement about the user: who they are, who it’s for, and until when.
Signature: Proves the identity provider made the assertion and nobody changed it. Verified with a certificate you already hold.
Audience: Which service provider the assertion is for. If it isn’t you, refuse it, however good the signature.
InResponseTo: The ID of the request the assertion answers. Ties the answer to a sign-in you started.
NotOnOrAfter: The time after which the assertion can’t be used. Minutes, not hours.
NameID: The identifier for the person, agreed between the two sides. Accounts are matched on it.
Replay: Presenting a captured assertion again. Prevented by remembering the IDs you’ve accepted until they expire.
Application session: The service provider’s own sign-in, with its own lifetime. The assertion only starts it.