[Openid-specs-fastfed] SCIM relationships

[Hardt, Dick]

Would you elaborate on what you mean by “the values may need mapping”?

/Dick

On 11/17/16, 3:39 PM, someone claiming to be "Phil Hunt (IDM)" <phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>> wrote:

The difference is that scim has standard attribute names like entitlements names etc. However entitlements are still an issue because the values may need mapping.

Phil

On Nov 17, 2016, at 2:05 PM, Hardt, Dick <dick at amazon.com<mailto:dick at amazon.com>> wrote:
As I survey the provisioning problems, just-in-time architectures are problematic for mobile applications. It seems much simpler to do provisioning centric option ii from the application’s perspective. The app gets changes when they happen and can act accordingly.

Would you elaborate on why entitlements, roles and groups are problematic?

/Dick


On 11/9/16, 2:12 AM, someone claiming to be "Openid-specs-fastfed on behalf of Dick Hardt via Openid-specs-fastfed" <openid-specs-fastfed-bounces at lists.openid.net<mailto:openid-specs-fastfed-bounces at lists.openid.net> on behalf of openid-specs-fastfed at lists.openid.net<mailto:openid-specs-fastfed at lists.openid.net>> wrote:

On today’s call we talked about

a:  how and where attribute mapping should occur
b:  using SCIM to do ongoing provisioning and updating

A couple of comments:

* While SCIM has standardized attributes(claims), the values for entitlements (something a user has/is given), roles (something a user is), and groups often tend to be problematic.  We talked about some of these cases. I think “who” does the mapping of these types of claims will depend largely on “b”.

*  There are actually several different types of relationships that could be established. Broadly speaking I would break them down into directory vs. provisioning centric:

Directory Centric

Where the application uses the OpenID Connect/SCIM profile and obtains an access token to the SCIM endpoint. That access token can be used in two ways:
i)  Just-in-time - the token is short lived and the app grabs what it needs every time the user logs into the app via connect

ii) Ongoing / delegated - the app polls the SCIM repository independently based on some other event criteria (eg. the SCIM provider issues an event saying the record has changed)

Provisioning Centric:

i) One-time: As part of fast fed, the application is provisioned with the first “copy” of the user.  No further updates are needed
ii) On-going provisioning system:   A provisioning system at the IDP is set up to send SCIM commands  to each application based on changes at the IDP
iii) On-going event system (loose-coupled):  The provisioning system sends events to the application. The applications reconcile and take appropriate action

There may be more variations here.

My gut feeling is that the directory method that will be easiest to standardize across all scenarios would be Directory-centric “ii” where the app either polls or uses SCIM events to trigger apps doing occasional reconciliation.  This might be easier to use at it has the fewest missing pieces and has a certain amount of adaptability to it. For example, an app could get data only once, it could update every time the user accesses, it could poll, or it could use events to “poll” only when a change notice has been delivered.


Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fastfed/attachments/20161117/3da13bb3/attachment.html>