<commit_before># saml

[![Build Status](https://travis-ci.org/goware/saml.svg?branch=master)](https://travis-ci.org/goware/saml)

Package `saml` provides tools and middleware for implementing [SAML based single
sign-on](https://auth0.com/blog/how-saml-authentication-works/).

Currently, the `saml` package depends on the
[xmlsec1](https://www.aleksey.com/xmlsec/index.html) command.

See
[_example/servers](https://github.com/goware/saml/tree/master/_example/servers)
for example implementations of IdP and SP servers.<commit_msg>add more details on how IdP-initiated is different from SP-initiated<commit_after># saml

[![Build Status](https://travis-ci.org/goware/saml.svg?branch=master)](https://travis-ci.org/goware/saml)

Package `saml` provides tools and middleware for implementing [SAML based single
sign-on](https://auth0.com/blog/how-saml-authentication-works/).

Currently, the `saml` package depends on the
[xmlsec1](https://www.aleksey.com/xmlsec/index.html) command.

See
[_example/servers](https://github.com/goware/saml/tree/master/_example/servers)
for example implementations of IdP and SP servers.

## SAML SSO basics

![SAML SSO process](https://user-images.githubusercontent.com/385670/30191334-d6ebe85e-9405-11e7-9e61-5d1cd7b47355.png)

### IdP initiated SSO

1. An user selects a service provider (SP) to log in via SSO, a typical use
   case for this is a login button on an intranet.
1. The user is asked by their login details (if not within a session yet).
1. The IdP creates an payload (`AuthnRequest`) containing the user information
   and signs it.
1. The IdP forces the user to submit the signed request to the SP they
   selected. This is typically done via a FORM that is auto-submitted via JavaScript.
1. The SP receives the message and determines if the signature is valid, among
   other details.
1. If the SP decides to trust the message, it can decode the payload with is
   expected to contain user information, such as e-mail address, unique ID and
   name details.
1. The SP uses the payload and provides access to the user.

### SP initiated SSO

1. An user tries to access a restricted URL at a SP.
1. The SP looks up the IdP that matches the private resource and redirects the
   user to a special IdP page. The original URL is passed as a `RelayState`
   parameter.
1. The user is asked by their login details.
1. The IdP creates an payload (`AuthnRequest`) containing the user information
   and signs it.
1. The IdP forces the user to submit the signed request to the SP they
   selected. This is typically done via a FORM that is auto-submitted via JavaScript.
1. The SP receives the message and determines if the signature is valid, among
   other details.
1. If the SP decides to trust the message, it can decode the payload with is
   expected to contain user information, such as e-mail address, unique ID and
   name details.
1. The SP uses the payload, provides access to the user and follows the
   `RelayState` URL.
1. The user gets access to the restricted URL.
{'fraction_non_alphanumeric': 0.08410596026490066, 'fraction_numerical': 0.018211920529801324, 'mean_word_length': 4.085858585858586, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 11, 'lorem ipsum': 0, 'www.': 2, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3534600', 'n_tokens_mistral': 916, 'n_tokens_neox': 894, 'n_words': 395}