Email thread on SCIM for multiple persona
From: Keith Hazelton <firstname.lastname@example.org>
Date: Tuesday, 9 October, 2012 3:53 PM
To: Chris Phillips <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>, osidm4he prov <firstname.lastname@example.org>
Subject: Re: CIFER and SCIM
Chris (et al.),
The particular driving use case here is the System of Record to Identity Registry work going on in CIFER. If you look at the Core Schema (https://spaces.at.internet2.edu/display/cifer/SOR-Registry+Core+Schema+Strawman), especially the Open Registry column, you'll see that the notion of "role" is central to the problem. Role here could be glossed as "affiliation" a la staff vs student and "positions" within one's role as an employee. The Identity Registry will need to mirror that structured information in a fairly rich form. In other words, I think this issue is front burner for CIFER Provisioning and Integration.
On Sep 24, 2012, at 8:32 AM, Chris Phillips wrote:
Hi Keith & all,
There are a few ways to handle the notion of a role in SCIM. The easiest
is to use the core schema multivalued attribute of 'role' and pack it with
whatever you like. There are no constraints to the value it contains so
it could be a simple (un)controlled vocabulary (Student, Staff, etc..) OR
it could be more driven to a URN like format such that it allows
computation of scope and span of control for instance.
If you want to be more sophisticated you can use schema extensions and
craft relationships to the subelements of role. This would be extending
the SCIM schema to a 'full fidelity' view of the data and is a designed in
function of SCIM.
I am not convinced there is value to go down this path yet though. There
are no consumers of the data in such a format as you are describing, and
if there is, it is very specialized. Considering the notion of role has
been around for more than a decade, there's existing work that could be
leveraged. The same goes for groups too.
That isn't to say that richer definitions are not a topic on the SCIM IETF
list, they are, specifically around groups and additional elements around
it but the dust has not settled much just yet. Not many use cases that
make sense have emerged to hang the conversation on.
To see where I'm coming from I frame the background of my answer against 2 things:
where does this play in the full lifecycle of an attribute?
what is the reason/business value requirement that the attribute supports?
In the case of groups or roles it is heavily skewed to access management
so leveraging existing systems and keeping it simple is the word of the
day. My view of the lifecycle of an attribute is also a supporting part of
my answer which to me looks like this:
---Directional flow --->
Administrate & Store -> Publish/transmit over the wire -> Decode &
Consume --> use as input to business process.
This is not much different than publishing attributes to LDAP or anywhere
else really. It has always been a pattern of 'master the data in a
relational database & publish a view of the data'.
I see the CIFER work in schema as the in the admin & storage phase and
makes a lot of sense to have a rich experience and control infrastructure
around the content of the attributes.
When it gets to transmitting it over the wire/serializing the data this is
where SCIM plays a role in being an empty vessel to be filled up and then
consumed on the other end. Rather than whip up another way to do this,
just use SCIM.
Keeping it simple benefits the right hand side of the lifecycle depiction
as end systems are not equipped to deal with complex data models. They
almost always have to have them decoded and likely diluted from the
original rich data model in order to shoe-horn them into the system.
Simplicity also keeps dev costs and support efforts down too
I see your point for userType though and the risk of conflicting intent
around userType and role in the SCIM schema.
I would classify your question in the same problem space as
eduCourseMember1 attribute.I think it would be useful to understand what
precisely would need to appear in one attribute as a 'tuple' for a person.
Repeating all the attributes seems awkward at the very least. I think
there's some interesting discussion to be had here.
On the note of where else to look, there's an older reference point to
SCIM on code.google.com2. This list is old and may be deprecated, but it
had a list of people who had implementations. It is by no means exhaustive.
Hope that covers the bases..more than happy to discuss further at I2FMM &
On 12-09-21 3:08 PM, "Keith Hazelton" <email@example.com> wrote:
Here's a query I just sent out to Chris Phillips who has been active in
the SCIM protocol development effort. I'm sending this copy to the P&I
and IdReg groups just to give a flavor of my current rudimentary thinking
about the issues. --Keith
In the CIFER schema work, the notion of role is more like a multi-valued
user profile with lots of associated sub-elements.
How would you handle that in SCIM?
- There is the singular user attribute: userType, but if a person has
multiple roles, there would have to be multiple instances of the user
object for a given person each with its own set of user schema elements.
Would that even work?
- There is the rather free-form multi-value "role" attribute on the user
schema, but that's a single string, so no place to hang a set of
sub-elements containing attributes associated with that role
- There is group, but like role it has no sub-elements off which to hang
- ...and a further question: I'm looking for implementations of the SCIM
API. I see this one, are there other ones? better ones?
Thanks in advance for any help you can offer, --Keith