Re: [scim] ExternalId - characteristics.
Erik Wahlström <erik.wahlstrom@nexusgroup.com> Thu, 11 September 2014 08:13 UTC
Return-Path: <erik.wahlstrom@nexusgroup.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266341A0667 for <scim@ietfa.amsl.com>; Thu, 11 Sep 2014 01:13:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0BsUhu9dUWm for <scim@ietfa.amsl.com>; Thu, 11 Sep 2014 01:13:48 -0700 (PDT)
Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46811A0669 for <scim@ietf.org>; Thu, 11 Sep 2014 01:13:47 -0700 (PDT)
Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 11 Sep 2014 10:14:19 +0200
Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 11 Sep 2014 10:14:18 +0200
Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Thu, 11 Sep 2014 10:14:18 +0200
From: Erik Wahlström <erik.wahlstrom@nexusgroup.com>
To: Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [scim] ExternalId - characteristics.
Thread-Index: AQHPyWGNPW6mqnfcxEStKJRB5tfEdJv2tFCAgAB1A4CAA2l8gIAADfcAgAAE8gCAAEgiAIAAATmAgACNOwA=
Date: Thu, 11 Sep 2014 08:14:17 +0000
Message-ID: <73D43C2C-CD53-4C00-B224-1B2C26FF32ED@nexusgroup.com>
References: <5E3A890D-33F8-47C5-AB50-25C037F70C4E@oracle.com> <540D56F3.4020002@tarent.de> <B8ABB7D7-A05A-4236-8AD5-CEA54830996A@oracle.com> <0F1F87FB-D09C-43E6-868A-1F8D6D66F639@oracle.com> <D035EB95.FB1BF%moransar@cisco.com> <30849414-27D0-4C4F-8813-D77C1BA621FE@oracle.com> <D0362FBB.FB1FD%moransar@cisco.com> <9BE69AC4-3C11-4832-8FF5-DA334D825048@oracle.com>
In-Reply-To: <9BE69AC4-3C11-4832-8FF5-DA334D825048@oracle.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.1878.6)
x-originating-ip: [10.75.110.12]
Content-Type: multipart/alternative; boundary="_000_73D43C2CCD534C00B2241B2C26FF32EDnexusgroupcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTtaIam4RmcbhSyCF9xE
Cc: "scim@ietf.org" <scim@ietf.org>, "Morteza Ansari (moransar)" <moransar@cisco.com>
Subject: Re: [scim] ExternalId - characteristics.
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 08:13:52 -0000
I think we are reading in more into the value then originally thought of. It’s meant to keep things like the DN or GUID of the AD user when provisioning them to the cloud so that it’s possible to use that attribute to reference the User in the cloud using a filter. I just tried to figure out a new name and renaming it to something more clear, but externalId is kinda good :) Maybe we should change the last sentence in the externalId description to make it possible to have 2 different clients working against the same resource in the same tenant (if that’s a potential future use case). From: "The service provider MUST always interpret the externalId as scoped to the client’s tenant." To: "The service provider MUST always interpret the externalId as scoped to the authenticated client." Just to make my self clear, I like the externalId to stay a singular attribute. / Erik On 11 Sep 2014, at 01:48, Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote: In the cloud, ownership becomes less clear. There may be many relationships with nodes acting more as peers. Is externalId even intended to be used here? Phil On Sep 10, 2014, at 16:43, "Morteza Ansari (moransar)" <moransar@cisco.com<mailto:moransar@cisco.com>> wrote: Totally agree on improving the language to get to a more clear definition. Can you expand the cloud to cloud use case? I actually don’t see why that would require multi-valued attribute for that. Cheers, Morteza On 9/10/14, 12:25 PM, "Phil Hunt" <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote: Coud to cloud is the use case I was thinking of. But its not clear to me the enterprise side of this is thought out well yet either — at least as far as privacy and security considerations go. ExternalIds sound a lot like connector Ids. A bit scary, because in meta-directory days, accounts very quickly tended to have a connecter ID per relationship. There is a lot of good and bad experiences here. :-) That’s why I’d like to have stronger definition of this value, its purpose, and security considerations. Phil @independentid www.independentid.com<http://www.independentid.com> phil.hunt@oracle.com On Sep 10, 2014, at 12:07 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote: Wearing chair hat: I think we need to let use cases drive this. What are the use cases for defining externalId as a multi-valued attribute or turning it into a complex attribute? Now with implementor hat: in almost all cases I have come across, there is a single authoritative source for the identity and hence a single value for the externalID with no semantics to be enforced by the service provider (etc. uniqueness) is all that is needed. I am sure if we dig we can come up with use cases in the larger context this would need to be more complex, but why couldn¹t that be handled as an extension? Cheers, Morteza On 9/10/14, 11:17 AM, "Phil Hunt" <phil.hunt@oracle.com> wrote: 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 phil.hunt@oracle.com On Sep 8, 2014, at 7:11 AM, Phil Hunt <phil.hunt@oracle.com> 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 <d.moebius@tarent.de> 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> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org<mailto:scim@ietf.org> https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org<mailto:scim@ietf.org> https://www.ietf.org/mailman/listinfo/scim
- [scim] ExternalId - characteristics. Phil Hunt
- Re: [scim] ExternalId - characteristics. Leif Johansson
- Re: [scim] ExternalId - characteristics. Erik Wahlström
- Re: [scim] ExternalId - characteristics. Kelly Grizzle
- Re: [scim] ExternalId - characteristics. David Möbius
- Re: [scim] ExternalId - characteristics. Phil Hunt
- Re: [scim] ExternalId - characteristics. Phil Hunt
- Re: [scim] ExternalId - characteristics. Morteza Ansari (moransar)
- Re: [scim] ExternalId - characteristics. Phil Hunt
- Re: [scim] ExternalId - characteristics. Morteza Ansari (moransar)
- Re: [scim] ExternalId - characteristics. Phil Hunt
- Re: [scim] ExternalId - characteristics. Erik Wahlström