[Openid-specs-fastfed] Preliminary feedback from IIW
darinm at amazon.com
Wed Oct 24 23:02:46 UTC 2018
Sharing preliminary feedback from IIW attendees:
Stuff The Spec Missed
** SSO adoption is incremental
-- Common Example: An organization creates ~10 local accounts in an app. (No SSO.) Later, someone enables SSO for the 10 employees. Later, someone sets up automated provisioning (via JIT or SCIM) & imports many more SSO-enabled employees.
-- Current spec presumes enabling SSO is a “1-shot” activity where the administrator turns on both SSO and Provisioning simultaneously. Instead, consider more incremental adoption of these features.
** Linking to local accounts
-- Once incrementalism is introduced, it’s necessary to know whether an SSO message represents a brand new user (who should be JIT provisioned) or sign-in by an existing user that was created locally before SSO was enabled.
-- Requires deduping on a unique identifier. TBD - How is that unique identifier specified.
-- ADP has an especially complex situation. Employees get provisioned into ADP _before_ they are employees. HR creates an employee record with an employeeID & minimal other data. The new hire submits paperwork online using “personal Gmail accounts” and phone numbers as identifiers. Finally, when the employee shows up at work, they receive a real corporate email address and corporate identifiers. ADP needs to “flip” the account to corporate SSO and disable the old Gmail logins.
** Multiple SSO protocols concurrently
-- Current spec requires negotiation of 1 protocol for SSO activities. Either SAML or OIDC.
-- But, multiple SSO protocols can be in use. Example: IdP started with SAML and Shibboleth. Later, they want to support mobile. So, they launch a new OIDC stack for mobile environments. Eventually, they want to migrate everything to OIDC. But, takes time. Until then, they are using SAML with the web endpoints of an app, and OIDC with the mobile version of the app.
-- General takeaway: SSO configuration changes over time. Consider supporting ongoing updates. “Rerun” the handshake to update existing SSO configurations?
** Multiple interop profiles
-- This is my own input, but I haven’t been comfortable with “The One” FastFed interoperability profile. OpenID sessions reiterated the # of OIDC profiles under development.
-- TBD: Consider supporting negotiation amongst several well-known interop profiles. FastFed can define a default profile for the simplest of cases, like a basic SaaS app that only needs username and email address.
We ran an IIW session to deep dive on IdP discovery from an email address.
The attendees confirmed the pain points of hosting WebFinger services under the root domain. One participant had previously built dynamic discovery based on domain. Many corporate customers were blocked because they were unable to host services under the root. Solution was a proxy as described below in (3).
The discussion circled around 3 alternatives:
-- Example: Instead of "https://<domain>/.well-known/webfinger" , flip it around into "https://webfinger.well-known.<domain>"
-- Pros: Easiest for everyone to implement. Just works for HTTP GETs. Enables CNAMES, which is nice when using 3rd party hosted IdPs and you want to point your domain at the hosted service.
-- Cons: No well-established patterns for reserved subdomains. More difficult to standardize. Subdomains existed in early versions of WebFinger but were cut because of these challenges.
(2) SRV records
-- Example: DNS SRV record for "webfinger.<domain>" that points to the location of that service.
-- Pros: There exists a well-established SRV registry.
(3) SRV records + Proxy
-- Example: Same as above, but run a proxy. For example: "webfinger.org". Make the WebFinger request to the proxy using a regular HTTP GET. Behind the scenes, proxy resolves the SRV record and invokes the authoritative WebFinger server.
-- Pros: Preserves the simple experience for developers. Uses standard mechanisms like SRV records behind the scenes.
-- Cons: Somebody has to run the proxy.
Finally, there was discussion about whether WebFinger was truly necessary here, as opposed to simple static configuration at an endpoint. WebFinger is necessary if multiple IdPs are used for a single domain. (WebFinger allows discovery of the specific IdP for a username in that domain.) There was mixed feedback from the room. Can dive in more on Thursday to clarify importance of this use case.
More information about the Openid-specs-fastfed