Subject: [scim] 11RE: userids, usernames, and group names

From: Emmanuel Dreux <[email-masked]>
Date: Sat, 1 Sep 2012 21:11:39 +0000

Hi Dale,

You have raised 2 very good points.

Point 1: We are (potentially) facing the same problem.
We have a customer who is using our product to synchronize their Active Directory with Google Apps.
When we've put our solution in place, we've discovered that he had 400 groups where the email address in Google was different from the group's SamAccounName in Active Directory.
Example:
Active Directory GroupName (=samAccountName) : MarkettingApp01
Google email: [email-masked]

We addressed the issue by creating a mapping table:Source=" MarkettingApp01" target="[email-masked]"

If we were synchronizing with SCIM, we would need the following schema:
displayName: MarkettingApp01
GroupId : [email-masked]

I re-read the spec after reading your mail and indeed an equivalent of the groupID attribute does not exist yet in the spec.

Point 2: We are facing the same issue too but we suggested to handle it differently with a mapping mechanisms between the source identifier and target identifier (that would be part of the IAM implementation but not the SCIM protocol).
Example:
Source :Active Directory:
Group : Grp01
Members:
CN=user1,OU=my,dc=mycompany,dc=com
CN=user2,OU=my,dc=mycompany,dc=com

Target: SAAS provider
Group : Grp01
Members:
UserID1
UserID2

How do we address it:
In our product, we maintain a mapping table between the source user and target user:
CN=user1,OU=my,dc=mycompany,dc=com = UserID1
CN=user2,OU=my,dc=mycompany,dc=com = UserID2

So, when we send the group membership, we send UserID1 and UserID2 (that are understandable by the target).

How would you imagine to handle this scenario differently?

--
Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Dale Olds [mailto:[email-masked]] 
Envoyé : vendredi 31 août 2012 23:59
À : [email-masked]
Objet : [scim] userids, usernames, and group names

In our scim implementation we assign the following meanings to these user attributes:

* id: unique, immutable, required, not intended to be typed by humans. 
The only identifier safe to store in external systems.

* userName: unique, mutable, required, though rarely changed in practice, not localized -- more like a keyword. It's what humans can use when they need to type in a reference to a user.

* displayName: not unique, mutable, optional, used as input to some display context but might not be literally displayed.

Access control for the id and userName fields is identical -- they are both essentially treated as identifiers, displayName is different. These meanings work for us. All 3 attributes are used for specific purposes, and I believe our use does not violate the current spec. BTW, thanks for changing userName to be mutable in 1.1.

We are now implementing groups.

IIRC, the only choice the spec gives for human readable group names is displayName, but we have tools (e.g. CLIs) that need to accept a reference to a group typed in by a user. We could use displayName for that purpose, but then we lose the displayName capability that we have for users.

I've checked for this issue in the list archives but did not see any discussion. Has the group discussed a naming attribute for groups that would be more like userName than displayName?

A related issue is compound attributes such as Users.groups and Groups.members. If Groups had groupName attribute similar to userName for users, it would be most useful if these attributes could have sub-attributes like this:

User:
{
   id: 111111
   userName: 'joe'
   groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] }

Group:
{
   id: 22222
   groupName: 'guides'
   members: [{display: 'Joey', name: 'joe', value: 11111}] }

I suppose we could add this capability as an extension, but would like to see if others would find this useful as well.

--Dale

---

From: Hasini Gunasinghe <[email-masked]>
Date: Mon, 3 Sep 2012 14:45:59 +0530

Hi Dale,

On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds <[email-masked]> wrote:

> * id: unique, immutable, required, not intended to be typed by humans. The
> only identifier safe to store in external systems.
>
> * userName: unique, mutable, required, though rarely changed in practice,
> not localized -- more like a keyword. It's what humans can use when they
> need to type in a reference to a user.
>
> * displayName: not unique, mutable, optional, used as input to some
> display context but might not be literally displayed.
>
> Access control for the id and userName fields is identical -- they are
> both essentially treated as identifiers, displayName is different. These
> meanings work for us. All 3 attributes are used for specific purposes, and
> I believe our use does not violate the current spec. BTW, thanks for
> changing userName to be mutable in 1.1.
>
> IIRC, the only choice the spec gives for human readable group names is
> displayName, but we have tools (e.g. CLIs) that need to accept a reference
> to a group typed in by a user. We could use displayName for that purpose,
> but then we lose the displayName capability that we have for users.
>
I do not see a reason why you can not use displayName of groups here. IIUC,
displayName for user and group are two separate attributes and you can use
them independently.

>
> I've checked for this issue in the list archives but did not see any
> discussion. Has the group discussed a naming attribute for groups that
> would be more like userName than displayName?
>
Another option would be externalId - which is defined in the common schema.

Thanks,
Hasini.

>
> A related issue is compound attributes such as Users.groups and
> Groups.members. If Groups had groupName attribute similar to userName for
> users, it would be most useful if these attributes could have
> sub-attributes like this:
>
> User:
> {
>   id: 111111
>   userName: 'joe'
> I suppose we could add this capability as an extension, but would like to
> see if others would find this useful as well.
>
> --Dale
>
> ______________________________**_________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/scim<https://www.ietf.org/mailman/listinfo/scim>
>

---

From: Emmanuel Dreux <[email-masked]>
Date: Mon, 3 Sep 2012 20:08:05 +0000

My understanding of Dale issue is the following:

I have a group in Google ( let's talk about Google if Active Directory does not ring bells):
DisplayName: Developpers
Group email address (= Id) : [email-masked]<mailto:[email-masked]>

How do you represent it in SCIM?
According to the spec here ( http://tools.ietf.org/html/draft-ietf-scim-core-schema-00#section-11.4), a "groupID" (or call it GroupUsername) is missing.

De : Hasini Gunasinghe [mailto:[email-masked]]
Envoyé : lundi 3 septembre 2012 11:16
À : Dale Olds
Cc : [email-masked]
Objet : Re: [scim] userids, usernames, and group names

Hi Dale,
On Sat, Sep 1, 2012 at 3:29 AM, Dale Olds <[email-masked]<mailto:[email-masked]>> wrote:
In our scim implementation we assign the following meanings to these user attributes:

* id: unique, immutable, required, not intended to be typed by humans. The only identifier safe to store in external systems.

IIRC, the only choice the spec gives for human readable group names is displayName, but we have tools (e.g. CLIs) that need to accept a reference to a group typed in by a user. We could use displayName for that purpose, but then we lose the displayName capability that we have for users.
I do not see a reason why you can not use displayName of groups here. IIUC, displayName for user and group are two separate attributes and you can use them independently.

Thanks,
Hasini.

User:
{
  id: 111111
  userName: 'joe'
  groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}]
}

Group:
{
  id: 22222
  groupName: 'guides'
  members: [{display: 'Joey', name: 'joe', value: 11111}]
}

--Dale

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Emmanuel Dreux <[email-masked]>
Date: Mon, 3 Sep 2012 20:12:34 +0000

And less problematic, Group Description is missing as well.
That's a field that usually our customers are asking to synchronize.

De : Emmanuel Dreux
Envoyé : lundi 3 septembre 2012 22:08
À : 'Hasini Gunasinghe'; Dale Olds
Cc : [email-masked]
Objet : RE: [scim] userids, usernames, and group names

De : Hasini Gunasinghe [mailto:[email-masked]]
Envoyé : lundi 3 septembre 2012 11:16
À : Dale Olds
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [scim] userids, usernames, and group names

Hi Dale,

Thanks,
Hasini.

User:
{
  id: 111111
  userName: 'joe'

Group:
{
  id: 22222
  groupName: 'guides'

--Dale

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 4 Sep 2012 16:16:47 +0000

I think description and groupName attributes make sense.  Using externalId for names may make more sense groups than for users, but my preference would be to use groupName to keep the resources similar.

> A related issue is compound attributes such as Users.groups and Groups.members. If Groups
> had groupName attribute similar to userName for users, it would be most useful if these attributes
> could have sub-attributes...

You can always fetch the group to get the additional data, but this would incur some cost.  I agree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all relationships.  For instance, this also applies to the "manager" attribute in the enterprise user extension.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Dreux
Sent: Monday, September 03, 2012 3:13 PM
To: Emmanuel Dreux; Hasini Gunasinghe; Dale Olds
Cc: [email-masked]
Subject: Re: [scim] userids, usernames, and group names

De : Emmanuel Dreux

Hi Dale,

Thanks,
Hasini.

User:
{
  id: 111111
  userName: 'joe'

Group:
{
  id: 22222
  groupName: 'guides'

--Dale

---

From: Dale Olds <[email-masked]>
Date: Tue, 04 Sep 2012 10:34:25 -0700

Hasini,

On 09/03/2012 02:15 AM, Hasini Gunasinghe wrote:
>
>     IIRC, the only choice the spec gives for human readable group
>     names is displayName, but we have tools (e.g. CLIs) that need to
>     accept a reference to a group typed in by a user. We could use
>     displayName for that purpose, but then we lose the displayName
>     capability that we have for users.
>
> I do not see a reason why you can not use displayName of groups here. 
> IIUC, displayName for user and group are two separate attributes and 
> you can use them independently.

I could have worded that better. Certainly we can (and do) use group 
displayName independently of user attributes.

The point I was trying to make is that if we use displayName for groups 
(requiring it to be unique, etc) then we can't also use it like we use 
displayNames for users. For groups, we'd like 3 similar attributes (with 
the same restrictions and meaning) as we the 3 we have for users:

id: immutable, unique
(group | user)Name: mutable, unique
displayName: mutable, non-unique

>
>     I've checked for this issue in the list archives but did not see
>     any discussion. Has the group discussed a naming attribute for
>     groups that would be more like userName than displayName?
>
Yes, we thought of that as well, but I'd like to reserve externalId to 
be used to hold a resource's id from an external system.

--Dale

---

From: Dale Olds <[email-masked]>
Date: Tue, 04 Sep 2012 10:49:34 -0700

Kelly,

On 09/04/2012 09:16 AM, Kelly Grizzle wrote:
>
> You can always fetch the group to get the additional data, but this 
> would incur some cost.  I agree that only including the displayName is 
> a bit arbitrary, though.  IMO we should take a look at this more 
> generally for all relationships.  For instance, this also applies to 
> the "manager" attribute in the enterprise user extension.
>
>

I agree that when we read a user's groups attribute, we could always 
fetch the groups to get the displayName, or whatever attribute we use as 
the groupName. But it's not just a performance issue to add that fetch, 
the access control on the group resource itself may be different than 
the users attribute -- in fact SCIM specifies different access control 
already in that the groups attribute is read-only. IMO, it's likely that 
access control for identifiers like id and userName may be different 
than access control for attributes such as postal addresses and phone 
numbers.

It would be easier to handle the access control needs of our client 
applications (with better performance) if we could get these three 
attributes as subattributes in the User 'groups' and Group 'members' 
attributes:

Users.groups: [{userName, id, displayName}, ...]

Groups.member: [{groupName, id, displayName}, ...]

--Dale

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 4 Sep 2012 18:11:01 +0000

Seems odd to have a rigid view, the object should be able to describe itself

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; [email-masked]; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

Kelly,

I agree that when we read a user's groups attribute, we could always fetch the groups to get the displayName, or whatever attribute we use as the groupName. But it's not just a performance issue to add that fetch, the access control on the group resource itself may be different than the users attribute -- in fact SCIM specifies different access control already in that the groups attribute is read-only. IMO, it's likely that access control for identifiers like id and userName may be different than access control for attributes such as postal addresses and phone numbers.

It would be easier to handle the access control needs of our client applications (with better performance) if we could get these three attributes as subattributes in the User 'groups' and Group 'members' attributes:

--Dale

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 4 Sep 2012 18:41:53 +0000

Tony, can you elaborate?  Are you saying that having the spec dictate that name, displayName, and id should be returned for references is odd?  In one sense, I agree with you.  Name and displayName are a bit arbitrary, but would probably be the most commonly used.

Perhaps SCIM should support expanding parts of references similar to OData - http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption.  It might make sense to allow retrieving only some of the referenced object's attributes rather than the full representation, though.

By default (ie - without any expansion) I think that name, displayName, and id are a good set of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; [email-masked]
Subject: Re: [scim] userids, usernames, and group names

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dale Olds
Sent: Tuesday, September 04, 2012 10:50 AM
To: Kelly Grizzle
Cc: Hasini Gunasinghe; [email-masked]<mailto:[email-masked]>; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

Kelly,

--Dale

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 4 Sep 2012 19:09:29 +0000

By default I think it makes sense to have some common attributes returned like ObjectId, ObjectType, Description, DisplayName, etc. but also believe we should allow for expanding parts of references (as ODATA does) for getting other.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Tuesday, September 04, 2012 11:42 AM
To: Anthony Nadalin; Dale Olds
Cc: Hasini Gunasinghe; [email-masked]; Emmanuel Dreux
Subject: Re: [scim] userids, usernames, and group names

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Anthony Nadalin
Sent: Tuesday, September 04, 2012 1:11 PM
To: Dale Olds; Kelly Grizzle
Cc: Hasini Gunasinghe; Emmanuel Dreux; [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] userids, usernames, and group names

Kelly,

--Dale

---

From: Trey Drake <[email-masked]>
Date: Tue, 4 Sep 2012 14:14:48 -0500

+1

On Sep 4, 2012, at 2:09 PM, Anthony Nadalin <[email-masked]> wrote:

> Perhaps SCIM should support expanding parts of references similar to OData -http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption.  It might make sense to allow retrieving only some of the referenced object’s attributes rather than the full representation, though.
>  
> By default (ie – without any expansion) I think that name, displayName, and id are a good set of attributes.  Alternatively, we could just return the id and require the client to request expansion if they want name and displayName.
>  
> --Kelly
>  
> Cc: Hasini Gunasinghe; Emmanuel Dreux;[email-masked]
> You can always fetch the group to get the additional data, but this would incur some cost.  I agree that only including the displayName is a bit arbitrary, though.  IMO we should take a look at this more generally for all relationships.  For instance, this also applies to the “manager” attribute in the enterprise user extension.
>  
>

---

From: Dale Olds <[email-masked]>
Date: Tue, 04 Sep 2012 23:12:48 -0700

Tony,

previously in this thread:
> the object should be able to describe itself

A self describing object sounds like self documenting code, but, like 
self documenting code, I'm all for it if it really works.

In the meantime, I would separate your list of common attributes below 
into two categories: identifiers and informational.

As I see it, the identifiers in your list are ObjectID and ObjectType. I 
include ObjectType here because, if objects can be retrieved from 
multiple endpoints depending on type (/Users vs. /Groups), we need to 
know the type to know how to identify the object.

The informational attributes are Description and DisplayName. As 
discussed earlier in this thread, retrieving them as subattributes in a 
multi-valued attribute can affect performance and access control, but 
they are not required to get more information about the object.

At least one identifier IS required. My point is that I think two 
identifiers are useful in different use cases. My purpose in this thread 
was to see if there would be support for another identifier for Group, 
similar to userName for User. As Kelly said, it keeps the resources 
similar. I'd also think that identifiers should be able to be retrieved 
as subattributes for multi-valued attributes that reference an object.

If you can make it so any reference can be expanded to arbitrary 
attributes (identifiers or informational) in a relatively easy way, that 
would work for me, but it sounds like a big addition. I haven't read 
OData yet. In this thread I was looking to see if there would be support 
for making identifiers for Group more like User -- which appears to me 
to be a fairly small addition.

--Dale

On 09/04/2012 12:09 PM, Anthony Nadalin wrote:
>
> By default I think it makes sense to have some common attributes 
> returned like ObjectId, ObjectType, Description, DisplayName, etc. but 
> also believe we should allow for expanding parts of references (as 
> ODATA does) for getting other.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Kelly Grizzle
> *Sent:* Tuesday, September 04, 2012 11:42 AM
> *To:* Anthony Nadalin; Dale Olds
> *Cc:* Hasini Gunasinghe; [email-masked]; Emmanuel Dreux
> *Subject:* Re: [scim] userids, usernames, and group names
>
> Tony, can you elaborate?  Are you saying that having the spec dictate 
> that name, displayName, and id should be returned for references is 
> odd?  In one sense, I agree with you. Name and displayName are a bit 
> arbitrary, but would probably be the most commonly used.
>
> Perhaps SCIM should support expanding parts of references similar to 
> OData - 
> http://www.odata.org/media/30002/OData.html#theexpandsystemqueryoption. It 
> might make sense to allow retrieving only some of the referenced 
> object's attributes rather than the full representation, though.
>
> By default (ie -- without any expansion) I think that name, 
> displayName, and id are a good set of attributes. Alternatively, we 
> could just return the id and require the client to request expansion 
> if they want name and displayName.
>
> --Kelly
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]> 
> *On Behalf Of *Anthony Nadalin
> *Sent:* Tuesday, September 04, 2012 1:11 PM
> *To:* Dale Olds; Kelly Grizzle
> *Cc:* Hasini Gunasinghe; Emmanuel Dreux; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [scim] userids, usernames, and group names
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Dale Olds
> *Sent:* Tuesday, September 04, 2012 10:50 AM
> *To:* Kelly Grizzle
> *Cc:* Hasini Gunasinghe; [email-masked] <mailto:[email-masked]>; 
> Emmanuel Dreux
> *Subject:* Re: [scim] userids, usernames, and group names
>
> Kelly,
>
>     You can always fetch the group to get the additional data, but
>     this would incur some cost.  I agree that only including the
>     displayName is a bit arbitrary, though.  IMO we should take a look
>     at this more generally for all relationships. For instance, this
>     also applies to the "manager" attribute in the enterprise user
>     extension.
>
>
> fetch the groups to get the displayName, or whatever attribute we use 
> as the groupName. But it's not just a performance issue to add that 
> fetch, the access control on the group resource itself may be 
> different than the users attribute -- in fact SCIM specifies different 
> access control already in that the groups attribute is read-only. IMO, 
> it's likely that access control for identifiers like id and userName 
> may be different than access control for attributes such as postal 
> addresses and phone numbers.
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 05 Sep 2012 06:23:28 -0400

+1

Igor