Skip to content

Home

Jump to bottom
aliaksander-samuseu edited this page Jan 19, 2018 · 23 revisions

Necessary improvements for inbound identity

  • automate how discovery happens.

  • saml is idp name, whats the equivalent for Google or Facebook?

  • how to signal which inbound identity to support? (SAML, OAuth, OpenID Connect, CAS).

  • which strategy? added to the state parameter.. then pass extra info. Take the JSON and add a top level strategy to it, then the app is signaling the strategy, then whatever extra information that strategy enables you to pass.

Alex's suggestions

General enhancements

  1. Would be nice to shift from our somewhat unconditional usage of "state" parameter to pass IDP's id to the script to our just added (3.1.2) custom authz request parameters functionality. The custom parameter it will be using must already exist OOTB. It also could be added as an additional feature, while keeping "state" parameter approach, just in case some implementers may prefer using parameter defined by spec instead of vendor-dependent approach.

Changes needed for compliance with USG and other customers' existing setups using old Asimba/SAML script

  1. At least USG employs "map_all_attr" mode of Asimba script operation which allows them to retrieve almost all of possible (defined at this specific instance) attributes from SAML response without need to set any attribute mappings for specific IDPs. I.e. it works like "catch everything" rule, by auto-generating a mapping array for all attributes found in Gluu's LDAP directory. In current Passport.js code we use hardcoded mappings which only cover a limited set of attributes. To achieve USG's requirements they would need to create an enormous hardcoded mapping array, and manage entries in it manually.

  2. Current implementation of mapping in config file used by Passport.js code won't scale well, as it's conceptually a bit clunky. Let's consider USG's case with there 1-2 dozens of IDPs registered (and that's probably is not a limit for huge vendors). Currently for Passport-SAML mappings are set at 2 different places at once: in SAML strategy's (Passport.js code) config file, and in script's properties itself. The most characteristic mapping phase is the one done by Passport, as it translates SAML attributes names to the ones used internally by Passport. SAML attributes' names come in different formats, and different IDPs in the list may use different formats for names they send. There may be groups of IDPs that use one similar format, as well. Manage this on per-IDP basis (as our current mapping approach implies) will be extremely cumbersome. USG partly resolves this issue by using their "catch everything" approach which alleviates problem of managing huge mapping array. Another solution to this problem could be implementing mapping profiles:

    • Actual mappings arrays are moved out of passport-saml-config.json and to a separate config file.

    • Format of the new file is JSON object, with entries like "id_01":{mapping_json_object}, "id_02":{mapping_json_object}.. JSON object format of the mapping should be also used to achieve another benefit of mappings in the old Asimba script: it should allow many-to-one mapping formats, allowing to map a bunch of different name formats to a single attribute. There also should be a special hardcoded mapping option implementing "wildcard mapping", ensuring that all names in SAML response will be mapped at least somehow (to achieve compliance with USG requirements)

    • "reverseMapping" properties of IDP entries in passport-saml-config.json only contain id of the mappings' set from the new file ("reverseMapping":"id_02",...). Thus it allows to create some general mapping profiles which then can be assigned to a group of IDPs at once, as a single mapping object. By editing this one single object you as well is able to update mappings of all IDPs it's assigned to.

  3. Another answer to the mapping issues is to move any kind of complex mapping processing out of Passport's code and back to the Jython code. Passport will do the most basic processing work on parsing a SAML response, then will either pass some kind of xml or json with full its content, or will extract all relevant identity items from it (attributes, issuer's id, timestamps etc) and pass only them, yet still in "raw" state (without resolving any SAML names in this blob). The rest of the work will be done by the Passport-SAML (jython) script itself (a lot of old code from Asimba script to reuse here). Pros: it gives us better control over attribute mappings and transformation, without investing too much effort into writing Node.js code; a lot of code to reuse from the old script Cons: it takes our Passport-SAML script even further away from the Passport-Social one, breaking the core design principle it seems to follow in the process (i.e. that Passport does all the "dirty", low-level work related to a specific auth strategy, and Jython scrypt is just a some general-purpose "high-level" code that takes an extracted set of attributes from Passport and simply creates/updates/logins user, i.e. it does uniform job regardless of whatever method was actually used under the hood; at least it seemed to me that was the original idea)

Clone this wiki locally