Shibboleth at NC State » Technical Documentation » Shibboleth Login Details

Detailed Trace of a Shibboleth Login

  1. Client visits a website protected by a Shibboleth SP

    • asks for
    • httpd server asks shibd server for credentials
    • shibd hasn't seen this client before
    • shibd saves the return URL in its memory (this appears to be keyed off the following SAML message ID)
    • shibd returns a redirect to the IdP, with a SAML message to initiate a login
  2. Client visits the IdP site to initiate a login

    • asks for
    • IdP verifies the SAML request, makes sure it knows about the SP
    • IdP issues a JSESSION cookie to track the login process
    • client gets sent on a couple redirect hops to eventually land on the login page.
  3. Client enters Unity ID and password on the login page, clicks to POST

    • POST to
    • includes the JSESSION cookie
    • IdP verifies the login, creates a new authenticated session
    • IdP returns an idp session cookie: shib_idp_session, only shared to urls.
    • IdP also sets a cookie shib_idp_exp_pwd, which is used to suppress repeated warnings about a soon-to-expire password.
    • client is bounced to a page that checks for attribute release.
  4. Client approves the attribute release page

    • POST to
    • includes the JSESSION and shib_idp_session cookies
    • saves the attribute release in two cookies:
    • shib_idp_session_ss = duration of this session
    • shib_idp_persistent_ss = expires in 1 year
    • attribute release is encrypted with sealer key, which is rotated daily and retained for 90 days
    • client is bounced to page that will redirect back to the SP.
    • page content uses javascript to force the browser to POST a SAML message back to the SP.
    • WARNING: if the SP is not an https URL, this javascript POST will throw an error message to the user warning that they are leaving a secured page for an unsecured one.
  5. Client POSTs the SAML message back to the SP

    • POST to
    • no cookies are sent (none exist for the SP, yet)
    • SAML message contains:
      • InResponseTo = the ID of the initiating SAML message
      • an authentication statement with attributes
      • statement is signed by the IdP's private key
      • statement is encrypted to the SP's public cert
    • the SP decodes/verifies this message and starts a new session
    • SP issues a session cookie: _shibsession_6465666175... the name contains a hex-encoded copy of the SP entityID, the cookie is only valid for URLs.
    • SP retrieves the originating URL from memory and issues a redirect back to that URL
  6. Client re-visits the website

    • asks for
    • includes the _shibsession_6465666175... cookie
    • shibd retrieves the session and sends the attributes back to httpd
    • httpd allows the connection and returns the page content


These pages are found on the Shibboleth Wiki: