Why not we maintain all the ids from external CSP - against the externalid ? Then we do not need to worry about doing two calls..
Thanks & regards, -Prabath On Tue, Oct 22, 2013 at 6:43 PM, Venura Kahawala <[email protected]> wrote: > Yes :) > > > On Tue, Oct 22, 2013 at 11:11 AM, Prabath Siriwardena <[email protected]>wrote: > >> >> >> >> On Tue, Oct 22, 2013 at 6:39 PM, Venura Kahawala <[email protected]> wrote: >> >>> Hi, >>> >>> Sorry for the trouble, but we do a filtering request to the provider >>> with user name (filter=userNameEq) and get the SCIM id and do the >>> provisioning to the outbound CSP. >>> >> >> :-) >> >> So we are back to the first question.. We do two calls when we do >> outbound provisioning..? One to get the id and then the PUT >> >> Thanks & regards, >> -Prabath >> >> >> >> >>> >>> Regards, >>> Venura >>> >>> >>> On Tue, Oct 22, 2013 at 11:05 AM, Prabath Siriwardena >>> <[email protected]>wrote: >>> >>>> But for outbound provisioning from IS we cannot do the same now - as we >>>> do not maintain the ids returned by the connected CSPs at the time we add >>>> the user..? >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> >>>> >>>> On Tue, Oct 22, 2013 at 6:21 PM, Venura Kahawala <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> Yes, I was wrong regarding the endpoint. Here is an example of PUT >>>>> operation on user resource. >>>>> >>>>> curl -v -k --user admin:admin -X *PUT* -d >>>>> "{"schemas":[],"name":{"familyName":"gunasinghe","givenName":"hasinitg"},"userName":"hasinitg","emails":[{"value":" >>>>> [email protected]","type":"work"},{"value":"[email protected]","type":"home"}]}" >>>>> --header "Content-Type:application/json" * >>>>> https://localhost:9443/wso2/scim/Users/48f7cfe5-f0e3-4a67-af7e-d762aa9ab215 >>>>> * >>>>> >>>>> Regards, >>>>> Venura >>>>> >>>>> >>>>> On Tue, Oct 22, 2013 at 10:37 AM, Prabath Siriwardena < >>>>> [email protected]> wrote: >>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Senior Software Engineer >>>>> >>>>> Mobile: +94 71 82 300 20 >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 >> > > > > -- > 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
