@boxyhq/saml-jackson 0.1.5-beta.118 → 0.1.5-beta.123

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.
@@ -152,7 +162,7 @@ curl --location --request POST 'http://localhost:6000/api/v1/saml/config' \
 - tenant: Jackson supports a multi-tenant architecture, this is a unique identifier you set from your side that relates back to your customer's tenant. This is normally an email, domain, an account id, or user-id
 - product: Jackson support multiple products, this is a unique identifier you set from your side that relates back to the product your customer is using
 
-The response returns a JSON with `client_id` and `client_secret` that can be stored against your tenant and product for a more secure OAuth 2.0 flow. If you do not want to store the `client_id` and `client_secret` you can alternatively use `client_id=tentant=<tenantID>&product=<productID>` and any arbitrary value for `client_secret` when setting up the OAuth 2.0 flow.
+The response returns a JSON with `client_id` and `client_secret` that can be stored against your tenant and product for a more secure OAuth 2.0 flow. If you do not want to store the `client_id` and `client_secret` you can alternatively use `client_id=tenant=<tenantID>&product=<productID>` and any arbitrary value for `client_secret` when setting up the OAuth 2.0 flow.
 
 ### 3. OAuth 2.0 Flow
 
@@ -175,7 +185,7 @@ https://localhost:5000/oauth/authorize
 ```
 
 - response_type=code: This is the only supported type for now but maybe extended in the future
-- client_id: Use the client_id returned by the SAML config API or use `tentant=<tenantID>&product=<productID>` to use the tenant and product IDs instead
+- client_id: Use the client_id returned by the SAML config API or use `tenant=<tenantID>&product=<productID>` to use the tenant and product IDs instead. **Note:** Please don't forget to URL encode the query parameters including `client_id`.
 - redirect_uri: This is where the user will be taken back once the authorization flow is complete
 - state: Use a randomly generated string as the state, this will be echoed back as a query parameter when taking the user back to the `redirect_uri` above. You should validate the state to prevent XSRF attacks
 
@@ -197,7 +207,7 @@ curl --request POST \
 ```
 
 - grant_type=authorization_code: This is the only supported flow, for now. We might extend this in the future
-- client_id: Use the client_id returned by the SAML config API or use `tentant=<tenantID>&product=<productID>` to use the tenant and product IDs instead
+- client_id: Use the client_id returned by the SAML config API or use `tenant=<tenantID>&product=<productID>` to use the tenant and product IDs instead. **Note:** Please don't forget to URL encode the query parameters including `client_id`.
 - client_secret: Use the client_secret returned by the SAML config API or any arbitrary value if using the tenant and product in the clientID
 - redirect_uri: This is where the user will be taken back once the authorization flow is complete. Use the same redirect_uri as the previous request
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@boxyhq/saml-jackson",
-  "version": "0.1.5-beta.118",
+  "version": "0.1.5-beta.123",
   "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);
         }
       );