Introduction to SAML authentication.

Jan 7, 2019 | Server administration, Technology | 0 comments

You have an application that requires authentication.  You would like to use your existing authentication system to validate your users however exposing that authentication system directly to the Internet or to the application would be dangerous or just undesirable.  A federated log in system sits between your authentication infrastructure and your application.  Using an agreed communication and encryption standard, sensitive account data is validated and the required account attributes are exposed to your application without ever exposing sensitive authentication details or the authentication and authorization system such as active directory.

Workflow

  • User visits the application and clicks a login link.
  • That login link sends an authentication request over to the federated login system.
  • The federated login system takes the credentials and validates them with active directory or a similar LDAP infrastructure.
  • The federated login takes the result of the login request and responds with it in an agreed format to the application.
  • The application takes the exposed account details from the response XML and provides application authorization as needed.

Useful terms

  • SP or Service Provider
    The application making authentication requests to the IdP Identity Provider.
  • Assertion Consumer Service URL
    The response URL that will be used by the IdP server to send users back to the service provider .
  • Unique ID
    An identifier for this specific application.
  • SAML Endpoint
  • The URL of the IdP server that will handle authentication requests.

Useful debug resource

Decode and encode SAML requests and responses using this great tool:
href=”http://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php”>http://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php

Notes on NameID

Documentation on name identifiers:
https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers

A transient identifier is intended to be used in one session. A persistent identifier is intended to be used across multiple sessions.
An identifier that is permanent is not revocable. So will persist during the lifetime of the session.
The following article would indicate that the NameID format is not required as the conf/saml/nameid.xml file should have a list of format identifiers to go through to determine the right one. However specifying a NameID format is more efficient as it cuts out that check on the IDP end. https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration

Example NameID

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

SAML2 spec documentation

The full SAML spec can be found here.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.