@boxyhq/saml-jackson 0.1.5-beta.119 → 0.1.5-beta.124

package/README.md

@@ -128,6 +128,16 @@ Kubernetes and docker-compose deployment files will be coming soon.
 
 Please follow the instructions [here](https://docs.google.com/document/d/1fk---Z9Ln59u-2toGKUkyO3BF6Dh3dscT2u4J2xHANE) to guide your customers in setting up SAML correctly for your product(s). You should create a copy of the doc and modify it with your custom settings, we have used the values that work for our demo apps.
 
+### 1.1 SAML profile/claims/attributes mapping
+As outlined in the guide above we try and support 4 attributes in the SAML claims - `id`, `email`, `firstName`, `lastName`. This is how the common SAML aattributes map over for most providers, but some providers have custom mappings. Please refer to the documentation on Identity Provider to understand the exact mapping.
+
+| SAML Attribute | Jackson mapping |
+|----------------|-----------------|
+|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier|id|
+|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress|email|
+|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname|firstName|
+|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname|lastName|
+
 ### 2. SAML config API
 
 Once your customer has set up the SAML app on their Identity Provider, the Identity Provider will generate an IdP or SP metadata file. Some Identity Providers only generate an IdP metadata file but it usually works for the SP login flow as well. It is an XML file that contains various attributes Jackson needs to validate incoming SAML login requests. This step is the equivalent of setting an OAuth 2.0 app and generating a client ID and client secret that will be used in the login flow.
@@ -189,11 +199,11 @@ The code can then be exchanged for a token by making the following request:
 curl --request POST \
   --url 'http://localhost:5000/oauth/token' \
   --header 'content-type: application/x-www-form-urlencoded' \
-  --data grant_type=authorization_code \
+  --data 'grant_type=authorization_code' \
   --data 'client_id=<clientID or tenant and product query params as described in the SAML config API section above>' \
-  --data client_secret=<clientSecret or any arbitrary value if using the tenant and product in the clientID> \
+  --data 'client_secret=<clientSecret or any arbitrary value if using the tenant and product in the clientID>' \
   --data 'redirect_uri=<redirect URL>' \
-  --data code=<code from the query parameter above>
+  --data 'code=<code from the query parameter above>'
 ```
 
 - grant_type=authorization_code: This is the only supported flow, for now. We might extend this in the future
@@ -226,15 +236,15 @@ If everything goes well you should receive a JSON response with the user's profi
 
 ```
 {
+  "id": <id from the Identity Provider>,
   "email": "sjackson@coolstartup.com",
   "firstName": "SAML"
-  "id": <id from the Identity Provider>,
-  "lastName": "Jackson",
+  "lastName": "Jackson"
 }
 ```
 
-- email: The email address of the user as provided by the Identity Provider
 - id: The id of the user as provided by the Identity Provider
+- email: The email address of the user as provided by the Identity Provider
 - firstName: The first name of the user as provided by the Identity Provider
 - lastName: The last name of the user as provided by the Identity Provider
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boxyhq/saml-jackson",
-  "version": "0.1.5-beta.119",
+  "version": "0.1.5-beta.124",
   "license": "Apache 2.0",
   "description": "SAML 2.0 service",
   "main": "src/index.js",

package/src/controller/oauth.js

@@ -186,11 +186,6 @@ const samlResponse = async (req, res) => {
   }
 
   const profile = await saml.validateAsync(rawResponse, validateOpts);
-  
-  // some providers don't return the id in the assertion, we set it to a sha256 hash of the email
-  if (profile && profile.claims && !profile.claims.id) {
-    profile.claims.id = crypto.createHash('sha256').update(profile.claims.email).digest('hex');
-  }
 
   // store details against a code
   const code = crypto.randomBytes(20).toString('hex');

package/src/saml/claims.js

@@ -0,0 +1,40 @@
+const mapping = [
+  {
+    attribute: 'id',
+    schema:
+      'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier',
+  },
+  {
+    attribute: 'email',
+    schema:
+      'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress',
+  },
+  {
+    attribute: 'firstName',
+    schema: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname',
+  },
+  {
+    attribute: 'lastName',
+    schema: 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname',
+  },
+];
+
+const map = (claims) => {
+  const profile = {
+    raw: claims,
+  };
+
+  mapping.forEach((m) => {
+    if (claims[m.attribute]) {
+      profile[m.attribute] = claims[m.attribute];
+    } else if (claims[m.schema]) {
+      profile[m.attribute] = claims[m.schema];
+    }
+  });
+
+  return profile;
+};
+
+module.exports = {
+  map,
+};

package/src/saml/saml.js

@@ -5,6 +5,7 @@ const thumbprint = require('thumbprint');
 const xmlbuilder = require('xmlbuilder');
 const crypto = require('crypto');
 const xmlcrypto = require('xml-crypto');
+const claims = require('./claims');
 
 const idPrefix = '_';
 const authnXPath =
@@ -120,6 +121,19 @@ module.exports = {
             return;
           }
 
+          if (profile && profile.claims) {
+            // we map claims to our attributes id, email, firstName, lastName where possible. We also map original claims to raw
+            profile.claims = claims.map(profile.claims);
+
+            // some providers don't return the id in the assertion, we set it to a sha256 hash of the email
+            if (!profile.claims.id) {
+              profile.claims.id = crypto
+                .createHash('sha256')
+                .update(profile.claims.email)
+                .digest('hex');
+            }
+          }
+
           resolve(profile);
         }
       );