[Openid-specs-fastfed] More Spec Questions
Brian Rose
brian.rose at sailpoint.com
Fri Nov 22 19:16:02 UTC 2019
Hey all,
I'm baaaaaaaaaaaaaaaack ...
1. In the FastFedProfile-SCIM-1.0-Draft-01.txt, Section 4.1 and 4.2 reference a "provider_authentication" in Section 3.1. Section 3.1 doesn't contain this key. It contains a "provider_identity". I assume this a typo?
1. In various places, the "provider_identity" object is specified as part of the "urn:ietf:params:fastfed:1.0:authentication:SCIM:FullLifeCycle" object. Since this object holds the "jwks_uri" information, it seems that it should be outside of the "urn:ietf:params:fastfed:1.0:authentication:SCIM:FullLifeCycle" object. A provider might not offer SCIM and both SAML and SCIM processes use these keys to sign JWT during the handshake.
1. Why is a lot of the information duplicated in the JWT payloads, for example, in the register POST and register response, that already exists in the main metadata exchange for both the app provider and IdP or Governance Provider? For instance, "provider_identity" but also "schemas", "provisioning profiles", etc. I am guessing that the schema, provisioning, and authentication information in the JWTs is what has already been chosen as the winner in the compatible protocols, but then should they be arrays in the payload?
* With regard to the jwks_uri, this information is contained in the main metadata exchange. Is it needed again in the JWT handshake payloads? During these steps, is the process to obtain the jwks_uri keys again, as part of the re-verification or compatibility? In my implementation, I have already whitelisted them and stored them off.
1. When an app and Idp/Governance provider are performing both setting up SSO and SCIM provisioning, there might be a delay while waiting for an administrator approval. Currently, on my side, when whitelisting, our application creates an entry where the primary key is tenantId, domain, and type. Type is "auth" or "provisioning." The type is set by the app because it knows what it is kicking off. We do this so that when setting up SCIM provisioning, we don't redo SSO flow every time. This now results in two entries in our whitelist (auth and provisioning). Due to the asynchronous nature, the registration endpoint will be called at some point by both flows. How do I know which registration flow (provisioning or SSO) to continue?
* This could also be an issue with the finalize endpoint. I think it would be nice to specify in the spec that the finalize endpoint is OPTIONAL for SSO flow and is ignored for SCIM governance flow. There is never a need for the app being governed to finalize to the governance provider. If there are any issues, the registration endpoint of the governance provider would never get called. If it did get called, that is enough for the flow to determine success. Since we said the finalize endpoints are not called on error cases, there is never a case where this makes sense to be called for governance flow.
Thanks,
Brian Rose
SailPoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191122/99bb1653/attachment.html>
More information about the Openid-specs-fastfed
mailing list