[Openid-specs-fastfed] Provisioning Related Questions/Suggestions
Brian Rose
brian.rose at sailpoint.com
Fri Nov 1 16:30:18 UTC 2019
Hi all,
I am starting to think about the provisioning side of the implementation. Here are some things to think about and potentially make changes to the current draft.
What should the idempotency requirements be for a Governance Provider and Application Provider?
* If the supported schemas change, will this cause a complete reattempt of setting up the SCIM application again?
* What happens if the SSO metadata changes (i.e., supported signing algorithms)? Since the metadata is combined, would this cause a reattempt of the governance handshake as well?
* Would the governance provider be responsible for disallowing it in this case since there are already entitlements, users, etc. associated with that application?
Should the SCIM schema and authorization profiles be defined in the metadata?
There seems to be a potential issue with the "schemas" concept in the FedFed "capabilities" metadata. This metadata specifies what SCIM schemas the application provider and governance provider support. By putting this information in the FastFed metadata, some issues arise.
This would cause duplication of metadata with the Application Server's SCIM "Schemas" and "ServiceProviderConfig" endpoint. An admin who is responsible for FastFed metadata must be made aware of the changes to the source of record SCIM server. It seems very easy for these to become out of sync.
As such, we believe the metadata should not specify this information, but instead, a URI to discovery the SCIM metadata. Two potential options are:
* Change the "provisioning_profiles" section of the metadata to be an array of objects with:
* type - "urn:ietf:params:fastfed:1.0:provisioning:SCIM:FullLifeCycle"
* scim_service_provider_config_uri - the "/ServiceProviderConfig" discovery endpoint for the Application Providers SCIM Server. This should be a public facing endpoint not requiring credentials.
* scim_schemas_uri - the "/Schemas" discovery endpoint for the Application Providers SCIM Server. This endpoint is not required to provider non-credentialed access.
* Since the SCIM endpoints have well-defined paths, keep the "provisioning_profiles" as-is, but update the spec to indicate that the "scim_service_uri" returned by the registration response ( Section 7.2.3.3) should be used to build the path to the "ServiceProviderConfig" and "Schemas" endpoint.
Once the endpoints are determined, calls should be made to the Application Provider's "ServiceProviderConfig" and "Schemas" endpoints and that metadata can be used by the Governance Provider to:
* determine compatibility and/or
* obtain values of supported SCIM functionality that will be used to configure application governance options.
Does the same apply for authentication profiles?
The "ServiceProviderConfig " metadata also specifies authentication profiles.
* How should this be used?
* Is this information a subset/duplication of FastFed's "oauth_metadata"?
Consistency
Only the "ServiceProviderConfig" endpoint is required to be public but the FastFed process will have given the ability to obtain a bearer token. So, the SCIM standards should apply without changes in the event the "Schemas" endpoint requires credentials. This flow also makes it align more closely with the SSO SAML metadata discovery paradigm. A side effect is that compatibility cannot be determined at time of metadata exchange, but further in the handshake process.
Other
The example JSON in Section 2.2 shows OIDC as an available authentication profile. In Section 6.6, what would this look like if the handshake is using OIDC instead of SAML? Should this maybe just be "metadata_uri" so that implementations aren't concerned with what the agreed upon authN is. It could just lookup the compatible key in the JSON object and use the "metadata_uri" value without having to know to prepend "oidc_" or "saml_".
Thanks!
Brian Rose
SailPoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20191101/2734ec21/attachment-0001.html>
More information about the Openid-specs-fastfed
mailing list