You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 14, 2018. It is now read-only.
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. Stormpath enables you to allow customers to log-in by authenticating with an external SAML Identity Provider.
941
+
942
+
#### Stormpath as a Service Provider
943
+
944
+
The specific use case that Stormpath supports is user-initiated single sign-on. In this scenario, a user requests a protected resource (e.g. your application). Your application, with the help of Stormpath, then confirms the users identity in order to determine whether they are able to access the resource. In SAML terminology, the user is the **User Agent**, your application (along with Stormpath) is the **Service Provider**, and the third-party SAML authentication site is the **Identity Provider** or **IdP**.
945
+
946
+
The broad strokes of the process are as follows:
947
+
948
+
- User Agent requests access from Service Provider
949
+
- Service Provider responds with redirect to Identity Provider
950
+
- Identity Provider authenticates the user
951
+
- Identity provider redirects user back to Service Provider along with SAML assertions.
952
+
- Service Provider receives SAML assertions and either creates or retrieves Account information
953
+
954
+
Just like with Mirror and Social Directories, the user information that is returned from the IdP is used by Stormpath to either identify an existing Account resource, or create a new one. In the case of new Account creation, Stormpath will map the information in the response onto its own resources. In this section we will walk you through the process of configuring your SAML Directory, as well as giving you an overview of how the SAML Authentication process works.
955
+
956
+
957
+
#### Configuring Stormpath as a Service Provider
958
+
959
+
Configuration is stored in the Directory's `Provider resource `. Both of these resources must also be linked with an `AccountStoreMapping`. Here we will explain to you the steps that are required to configure Stormpath as a SAML Service Provider.
960
+
961
+
##### Step 1: Gather IDP Data
962
+
963
+
You will need the following information from your IdP:
964
+
965
+
-**SSO Login URL** - The URL at the IdP to which SAML authentication requests should be sent. This is often called an "SSO URL", "Login URL" or "Sign-in URL".
966
+
-**SSO Logout URL** - The URL at the IdP to which SAML logout requests should be sent. This is often called a "Logout URL", "Global Logout URL" or "Single Logout URL".
967
+
-**Signing Cert** - The IdP will digitally sign auth assertions and Stormpath will need to validate the signature. This will usually be in .pem or .crt format, but Stormpath requires the text value.
968
+
-**Signing Algorithm** - You will need the name of the signing algorithm that your IdP uses. It will be either "RSA-SHA256" or "RSA-SHA1".
969
+
970
+
##### Step 2: Configure Your SAML Directory
971
+
972
+
Input the data you gathered in Step 1 above into your Directory's Provider resource, and then pass that along as part of the Directory creation HTTP POST:
> Notice that new lines in the certificate are separated with a ``\n`` character.
991
+
992
+
993
+
##### Retrieve Your Service Provider Metadata
994
+
995
+
Next you will have to configure your Stormpath-powered application as a Service Provider in your Identity Provider. This means that you will need to retrieve the correct metadata from Stormpath.
996
+
997
+
In order to retrieve the required values, start by sending a GET to the Directory's Provider:
-**Assertion Consumer Service URL**: This is the location the IdP will send its response to.
1007
+
-**X509 Signing Certificate**: The certificate that is used to sign the requests sent to the IdP. If you retrieve XML, the certificate will be embedded. If you retrieve JSON, you'll have to follow a further ``/x509certificates`` link to retrieve it.
1008
+
1009
+
You will also need two other values, which will always be the same:
1010
+
1011
+
-**SAML Request Binding:** Set to ``HTTP-Redirect``.
1012
+
-**SAML Response Binding:** Set to ``HTTP-Post``.
1013
+
1014
+
##### Step 4: Configure Your Service Provider in Your Identity Provider
1015
+
1016
+
Log-in to your Identity Provider (Salesforce, OneLogin, etc) and enter the information you retrieved in the previous step into the relevant application configuration fields. The specific steps to follow here will depend entirely on what Identity Provider you use, and for more information you should consult your Identity Provider's SAML documentation.
1017
+
1018
+
##### Step 5: Configure Your Application
1019
+
1020
+
The Stormpath `Application` Resource has two parts that are relevant to SAML:
1021
+
1022
+
- an ``authorizedCallbackUri`` Array that defines the authorized URIs that the IdP can return your user to. These should be URIs that you host yourself.
1023
+
- an embedded ``samlPolicy`` object that contains information about the SAML flow configuration and endpoints.
1024
+
1025
+
```
1026
+
$application->setAuthorizedCallbackUris([
1027
+
'http://myapplication.com/whatever/callback',
1028
+
'http://myapplication.com/whatever/callback2'
1029
+
]);
1030
+
1031
+
$application->save();
1032
+
1033
+
```
1034
+
1035
+
##### Step 6: Add the SAML Directory as an Account Store
1036
+
1037
+
Now you last thing you have to do is map the new Directory to your Application with an Account Store Mapping.
1038
+
1039
+
1040
+
##### Step 7: Configure SAML Assertion Mapping
1041
+
1042
+
The Identity Provider's SAML response contains assertions about the user's identity, which Stormpath can use to create and populate a new Account resource.
The Attribute Assertions (`<saml:AttributeStatement>`) are brought into Stormpath and become Account and customData attributes.
1059
+
1060
+
SAML Assertion mapping is defined in an **attributeStatementMappingRules** object found inside the Directory's Provider object, or directly: `/v1/attributeStatementMappingRules/$RULES_ID`.
1061
+
1062
+
##### Mapping Rules
1063
+
1064
+
The rules have three different components:
1065
+
1066
+
- **name**: The SAML Attribute name
1067
+
- **nameFormat**: The name format for this SAML Attribute, expressed as a Uniform Resource Name (URN).
1068
+
- **accountAttributes**: This is an array of Stormpath Account or customData (`customData.$KEY_NAME`) attributes that will map to this SAML Attribute.
1069
+
1070
+
1071
+
1072
+
In order to create the mapping rules, we simply send the following:
0 commit comments