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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
