Subject: Re: [scim] scim Digest, Vol 33, Issue 11

From: Steve Moyer <[email-masked]>
Date: Wed, 10 Sep 2014 15:43:00 -0400 (EDT)

We've got a system deployed based on the preliminary SCIM specification with about 2.5M users ... I think we could live with externalId being multi-valued as long as it is both typed *and* has a primary flag.  Our SCIM users are mapped to LDAP attributes and externalId becomes uid and is part of a user's DN, so any changes to the externalId field will require code changes for us (we knew it was a preliminary specification when we started).

Thanks to everyone for the extensive discussion ... we're going to have something wonderful in the end!

Steve Moyer

--

“The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.” - Wilhelm Stekel

----- Original Message -----
From: [email-masked]
To: [email-masked]
Sent: Wednesday, September 10, 2014 3:01:21 PM
Subject: scim Digest, Vol 33, Issue 11

Send scim mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of scim digest..."

Today's Topics:

   1. Re: ExternalId - characteristics. (Phil Hunt)

----------------------------------------------------------------------

Message: 1
Date: Wed, 10 Sep 2014 11:17:59 -0700
From: Phil Hunt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [scim] ExternalId - characteristics.
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252

Any feedback on this topic? I?ve heard very different conflicting opinions on whether externalId should be multi-valued.

Further, in the multi-value option you could say you say that each value should have a type.

I think we need more clarification on how this is to be used.

I am concerned that the notion that a single client controls externalId is fits only an initial deployment. I would expect that over time, mxn relationships will emerge where many clients connect or reference the same cloud user.  Having a separate externalId assigned by each different client involves a data type or access control model that SCIM currently doesn?t support.

For me, I can go either way?but that?s mainly because externalId is a bit mysterious to me.

Phil

@independentid
www.independentid.com
[email-masked]

On Sep 8, 2014, at 7:11 AM, Phil Hunt <[email-masked]> wrote:

> I think the idea that certain values may need to be restricted to certain clients is an enhancement. It sounds like an access control feature. 
> 
> That said, it sounds like a security considerations issue. 
> 
> Phil
> 
>> On Sep 8, 2014, at 0:12, David M?bius <[email-masked]> wrote:
>> 
>> +1
>> 
>> for multivalue and that it can have a name for each client.
>> 
>> Doesn anyone has a idear how to solve the problems if one user belongs to several clients but not all values should be seen by all clients?
>> 
>> David
>> 
>>> On 06.09.2014 01:30, Phil Hunt wrote:
>>> Looking at the definition for the externalId attribute, I see:
>>> 
>>>      {
>>>        "name" : "externalId",
>>>        "type" : "string",
>>>        "multiValued" : false,
>>>        "description" : "An identifier for the Resource as defined by the Service Consumer.",
>>>        "required" : true,
>>>        "caseExact" : false,
>>>        "mutability" : "readWrite",
>>>        "returned" : "default",
>>>        "uniqueness" : "none"
>>>      },
>>> 
>>> 
>>> Is this correct. Should it not be multi-valued and unique (although
>>> enforcement is assumed to be the client)?
>>> 
>>> I?m thinking multi-valued because there may be multiple clients
>>> associating with the same resource in the cloud.  Each clients wants to
>>> leave a unique identifier in externalId.
>>> 
>>> Any objections?
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com <http://www.independentid.com>
>>> [email-masked] <mailto:[email-masked]>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> scim mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/scim
>> 
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim

------------------------------

Subject: Digest Footer

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

------------------------------

End of scim Digest, Vol 33, Issue 11
************************************

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 10 Sep 2014 23:48:51 +0000

Steve,

Can you clarify this a bit please?  Does this mean your current
implementation treat externalId as a single valued attribute?

Cheers,
Morteza

On 9/10/14, 12:43 PM, "Steve Moyer" <[email-masked]> wrote:

>We've got a system deployed based on the preliminary SCIM specification
>with about 2.5M users ... I think we could live with externalId being
>multi-valued as long as it is both typed *and* has a primary flag.  Our
>SCIM users are mapped to LDAP attributes and externalId becomes uid and
>is part of a user's DN, so any changes to the externalId field will
>require code changes for us (we knew it was a preliminary specification
>when we started).
>
>³The mark of the immature man is that he wants to die nobly for a cause,
>while the mark of the mature man is that he wants to live humbly for
>one.² - Wilhelm Stekel
>
>Any feedback on this topic? I?ve heard very different conflicting
>opinions on whether externalId should be multi-valued.
>
>I am concerned that the notion that a single client controls externalId
>is fits only an initial deployment. I would expect that over time, mxn
>relationships will emerge where many clients connect or reference the
>same cloud user.  Having a separate externalId assigned by each different
>client involves a data type or access control model that SCIM currently
>doesn?t support.
>
>> I think the idea that certain values may need to be restricted to
>>certain clients is an enhancement. It sounds like an access control
>>feature. 
>> 
>>> Doesn anyone has a idear how to solve the problems if one user belongs
>>>to several clients but not all values should be seen by all clients?
>>> 
>>> David
>>>