In that case its with an id - not a direct PUT to /Users. Its like /Users/id
To sort out any confusion here we need to look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 So - it looks like just doing a PUT on /Users is not quite correct - we need to identify the resource in the Request-URI. "The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response." Thanks & regards, -Prabath On Tue, Oct 22, 2013 at 5:55 PM, Venura Kahawala <[email protected]> wrote: > Hi, > > > > On Tue, Oct 22, 2013 at 10:17 AM, Prabath Siriwardena <[email protected]>wrote: > >> >> >> >> On Tue, Oct 22, 2013 at 5:41 PM, Venura Kahawala <[email protected]> wrote: >> >>> Hi, >>> >>> Also - how spec compliant - is it to do a PUT directly on Users ? >>>> >>> >>> Doing a PUT operation on user resource is acceptable but this operation >>> will replace the resource. We need to implement the PATCH operation in >>> order to perform correct update operation. >>> >> >> Can you please point to the spec...? >> > > Here [1] it defines the operations supported. In [2] it provides a sample > SCIM PUT operation on user resource. > > >> >> Thanks & regards, >> -Prabath >> >> >>> >>> >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> On Tue, Oct 22, 2013 at 5:01 PM, Venura Kahawala <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> We do not send two separate calls, Since user name is a unique >>>>> attribute SCIM providers handle the request by taking the user name and >>>>> identifying to which resource the operation should be applied. >>>>> >>>>> Regards, >>>>> Venura >>>>> >>>>> >>>>> On Tue, Oct 22, 2013 at 9:15 AM, Prabath Siriwardena <[email protected] >>>>> > wrote: >>>>> >>>>>> >>>>>> On Tue, Oct 22, 2013 at 3:09 PM, Ishara Karunarathna < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> No, We do not maintain a list, instead we get the scimId of the user >>>>>>> being provisioned from the particular provider >>>>>>> by filtering with user name. >>>>>>> >>>>>> >>>>>> So - for each outbound provisioning - there are two calls..? One to >>>>>> get the id - and then to do the actual SCIM provisioning request ? >>>>>> >>>>>> Thanks & regards, >>>>>> -Prabath >>>>>> >>>>>>> >>>>>>> In consumer side externaid is useful, but in the [2] case it would >>>>>>> be better if we need, keep returned scimId's mapping to >>>>>>> Consumer's scimId as it it unique. >>>>>>> >>>>>>> Thanks, >>>>>>> -Ishara >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 22, 2013 at 4:53 AM, Prabath Siriwardena < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> When IS provisions users to other connected systems - are we >>>>>>>> maintaining the list of id's returned by each CSP...? >>>>>>>> >>>>>>>> IMO externaid is also useful. A given externalid could map to >>>>>>>> multiple id's returned by CSPs. >>>>>>>> >>>>>>>> Thanks & regards, >>>>>>>> -Prabath >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Oct 22, 2013 at 8:25 AM, Ishara Karunarathna < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Prabath, >>>>>>>>> >>>>>>>>> id (scimId attribute) >>>>>>>>> Mandatory attribute, Random value generated by each Service >>>>>>>>> Provider, Unique to each service provider, immutable >>>>>>>>> >>>>>>>>> exernalId >>>>>>>>> Is not an mandatory attribute, Will be generated by consumers, >>>>>>>>> unique across all Service Providers, not immutable >>>>>>>>> >>>>>>>>> userName >>>>>>>>> Mandatory attribute, generated by consumer, unique across all >>>>>>>>> Service Providers, immutable >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. SCIM consumer sends a provisioning request to IS - which is the >>>>>>>>> SCIM CSP. >>>>>>>>> If exernalId is available it will be stored as a user attribute. >>>>>>>>> Randomly created a id and store under scimId attribute >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. [1] & Identity Server provisions the user to other CSPs >>>>>>>>> If externalId available it will provision to other service >>>>>>>>> providers >>>>>>>>> scimId will not provision, each service provider will create its >>>>>>>>> own scimId >>>>>>>>> >>>>>>>>> >>>>>>>>> 3. Adding user from the IS management console and provision the >>>>>>>>> user to other connected CSP. >>>>>>>>> When a user added from Management console automatically scimId >>>>>>>>> generated and stored as user attribute. >>>>>>>>> externalId will not be generated >>>>>>>>> When that user provision to other service providers it will work >>>>>>>>> as scenario [2] >>>>>>>>> >>>>>>>>> In all of these scenarios username will be unique and will >>>>>>>>> provision to other service providers. >>>>>>>>> >>>>>>>>> Users generated from Management console will provision to service >>>>>>>>> providers only if they are configured as global service providers. >>>>>>>>> >>>>>>>>> implementation will not change for LDAP and JDBC but in LDAP or AD >>>>>>>>> claim mapping should be set to SCIM attributes (externalId, scimId >>>>>>>>> etc). >>>>>>>>> >>>>>>>>> IMO externalId is not an useful attribute in the spec. [1] here >>>>>>>>> there are some arguments on this. >>>>>>>>> [1] http://www.infoq.com/articles/scim-data-model-limitations >>>>>>>>> >>>>>>>>> Please add something mission or wrong. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Oct 21, 2013 at 10:45 PM, Prabath Siriwardena < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> There are three use cases.. >>>>>>>>>> >>>>>>>>>> 1. SCIM consumer sends a provisioning request to IS - which is >>>>>>>>>> the SCIM CSP. >>>>>>>>>> 2. [1] & Identity Server provisions the user to other CSPs >>>>>>>>>> 3. Adding user from the IS management console and provision the >>>>>>>>>> user to other connected CSP. >>>>>>>>>> >>>>>>>>>> How do we handle id/externalid/userName in above three cases..? >>>>>>>>>> Also please explain this both in the case of LDAP and JDBC based user >>>>>>>>>> stores. >>>>>>>>>> >>>>>>>>>> For [2] and [3] - what is the externalid we have..? >>>>>>>>>> >>>>>>>>>> *id* Unique identifier for the SCIM Resource as defined by the >>>>>>>>>> Service Provider. Each representation of the Resource MUST include a >>>>>>>>>> non-empty id value. This identifier MUST be unique across the Service >>>>>>>>>> Provider’s entire set of Resources. It MUST be a stable, >>>>>>>>>> non-reassignable >>>>>>>>>> identifier that does not change when the same Resource is returned in >>>>>>>>>> subsequent requests. The value of the id attribute is always issued >>>>>>>>>> by the >>>>>>>>>> Service Provider and MUST never be specified by the Service Consumer. >>>>>>>>>> bulkId: is a reserved keyword and MUST NOT be used in the unique >>>>>>>>>> identifier. REQUIRED and READ-ONLY. >>>>>>>>>> >>>>>>>>>> *externalId* An identifier for the Resource as defined by the >>>>>>>>>> Service Consumer. The externalId may simplify identification of the >>>>>>>>>> Resource between Service Consumer and Service provider by allowing >>>>>>>>>> the >>>>>>>>>> Consumer to refer to the Resource with its own identifier, obviating >>>>>>>>>> the >>>>>>>>>> need to store a local mapping between the local identifier of the >>>>>>>>>> Resource >>>>>>>>>> and the identifier used by the Service Provider. Each Resource MAY >>>>>>>>>> include >>>>>>>>>> a non-empty externalId value.The value of the externalId attribute is >>>>>>>>>> always issued be the Service Consumer and can never be specified by >>>>>>>>>> the >>>>>>>>>> Service Provider. The Service Provider MUST always interpret the >>>>>>>>>> externalId >>>>>>>>>> as scoped to the Service Consumer’s tenant. >>>>>>>>>> >>>>>>>>>> *userName* Unique identifier for the User, typically used by the >>>>>>>>>> user to directly authenticate to the service provider. Often >>>>>>>>>> displayed to >>>>>>>>>> the user as their unique identifier within the system (as >>>>>>>>>> opposed to id or externalId, which are generally opaque and not >>>>>>>>>> user-friendly identifiers). Each User MUST include a non-empty >>>>>>>>>> userName >>>>>>>>>> value. This identifier MUST be unique across the Service Consumer’s >>>>>>>>>> entire >>>>>>>>>> set of Users. REQUIRED. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks & Regards, >>>>>>>>>> Prabath >>>>>>>>>> >>>>>>>>>> Mobile : +94 71 809 6732 >>>>>>>>>> >>>>>>>>>> http://blog.facilelogin.com >>>>>>>>>> http://RampartFAQ.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ishara Karunarathna >>>>>>>>> Software Engineer >>>>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>>>> >>>>>>>>> email: [email protected], blog: isharaaruna.blogspot.com, >>>>>>>>> mobile: +94 718211678 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> Prabath >>>>>>>> >>>>>>>> Mobile : +94 71 809 6732 >>>>>>>> >>>>>>>> http://blog.facilelogin.com >>>>>>>> http://RampartFAQ.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ishara Karunarathna >>>>>>> Software Engineer >>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>> >>>>>>> email: [email protected], blog: isharaaruna.blogspot.com, >>>>>>> mobile: +94 718211678 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks & Regards, >>>>>> Prabath >>>>>> >>>>>> Mobile : +94 71 809 6732 >>>>>> >>>>>> http://blog.facilelogin.com >>>>>> http://RampartFAQ.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Senior Software Engineer >>>>> >>>>> Mobile: +94 71 82 300 20 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com >>>> http://RampartFAQ.com >>>> >>> >>> >>> >>> Both above mentioned improvements have been suggested in the SCIM road >>> map thread ([IS] Roadmap for user/identity provisioning). >>> >>> Regards, >>> Venura >>> >>> -- >>> Senior Software Engineer >>> >>> Mobile: +94 71 82 300 20 >>> >>> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> > > > [1] http://www.simplecloud.info/specs/draft-scim-api-01.html#api > [2] > http://www.simplecloud.info/specs/draft-scim-api-01.html#edit-resource-with-put > > Regards, > Venura > -- > Senior Software Engineer > > Mobile: +94 71 82 300 20 > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
