On Fri, Sep 1, 2017 at 10:36 PM, Johann Nallathamby <[email protected]> wrote:
> In that case can we set a threadlocal variable in order to identify the > SCIM version? Based on that the correct listener will execute and the other > will not. Since SCIM1.1 listener will check for it's related threadlocal > and SCIM2.0 listener it's related threadlocal there is not coupling between > the two implementations. All the SCIM operations must set this threadlocal. > I don't see any better solution for this problem. > > Regards, > Johann. > > On Thu, Aug 31, 2017 at 6:54 PM, Sathya Bandara <[email protected]> wrote: > >> >> >> On Thu, Aug 31, 2017 at 2:18 PM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Hi Sathya, >>> >>> On Thu, Aug 31, 2017 at 12:29 PM, Sathya Bandara <[email protected]> >>> wrote: >>> >>>> Hi Johann, >>>> >>>> IMO having two separate LDAP attributes for the same claims in both >>>> SCIM1 and SCIM2 would be redundant and cause problems in maintaining user >>>> attributes. >>>> >>> >>> True. I didn't say this is the correct solution. I only mentioned it as >>> a work around for someone who wants to use both without any conflicts until >>> we find a alternative or deprecate SCIM 1.1 :) >>> >>> >>>> If we need to have both listeners enabled at the time I would suggest >>>> to use a common util method to generate IDs and do the mappings for the >>>> claims that are common to both protocols. >>>> >>> >>> Didn't get how this would help exactly. May be I am missing some context. >>> >>> However, after reading through your first reply again, now I have >>> another question. Why do both the listeners get executed when adding a new >>> user? I know they both will get triggered. But can't we look at the dialect >>> URI at the top and skip the execution if it's not for that listener? >>> >>> When adding a user through normal approach(management console) when SCIM >>> is enabled, it is not possible to figure out the dialect URI. In this case >>> this will not work AFAIU. >>> >> > Hmm.. > True, that when adding through management console we can't identify the SCIM version. But do we need to? If both the listeners are doing the same change in the user store for SCIM1 and SCIM2, then either of the listeners doing the change will be enough right? I think this is getting a bit too complicated over mail. We can chat offline if needed and come to a conclusion :) > > >> >>> Thanks, >>> Sathya >>> >>> Regards, >>> Johann. >>> >>> >>>> >>>> Thanks, >>>> Sathya >>>> >>>> On Thu, Aug 31, 2017 at 11:37 AM, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> Will it work if we have two separate attributes for the problematic >>>>> attributes like SCIM ID? If that works I guess that is one solution. >>>>> >>>>> Or we need to have one listener for both SCIM 1 and SCIM2. But don't >>>>> think that's a good solution. Introduces direct coupling between two >>>>> implementations. >>>>> >>>>> Regards, >>>>> Johann. >>>>> >>>>> On Wed, Aug 30, 2017 at 6:33 PM, Sathya Bandara <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Thilina, >>>>>> >>>>>> If we enable both SCIM1 and SCIM2 listeners at the same time two >>>>>> different SCIM IDs will be generated for the same user when adding a new >>>>>> user through SCIM. Also both SCIM1 and SCIM2 claims are mapped to the >>>>>> same >>>>>> LDAP user attributes. Even though both listeners get triggered only the >>>>>> SCIM1 ID is mapped to the user ID attribute. But the SCIM2 user creation >>>>>> response will contain the SCIM ID generated by SCIM2 listener. >>>>>> >>>>>> Thanks, >>>>>> Sathya >>>>>> >>>>>> On Wed, Aug 30, 2017 at 6:25 PM, Thilina Madumal <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> While I was trying to fix IDENTITY-6315 >>>>>>> <https://wso2.org/jira/browse/IDENTITY-6315> I got to know that we >>>>>>> can't enable both SCIM1 and SCIM2 at the same time in WSO2 Identity >>>>>>> Server. >>>>>>> Is it because of this specific issue or is there any other reasons? >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Thilina. >>>>>>> >>>>>>> -- >>>>>>> *Thilina Madumal* >>>>>>> *Software Engineer | **WSO2* >>>>>>> Email: [email protected] >>>>>>> Mobile: *+ <+94%2077%20767%201807>94 774553167* >>>>>>> Web: <http://goog_716986954>http://wso2.com >>>>>>> >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sathya Bandara >>>>>> Software Engineer >>>>>> WSO2 Inc. http://wso2.com >>>>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>>>> >>>>>> <+94%2071%20411%205032> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> >>>>> *Johann Dilantha Nallathamby* >>>>> Senior Lead Solutions Engineer >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - *+94777776950* >>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>> >>>> >>>> >>>> >>>> -- >>>> Sathya Bandara >>>> Software Engineer >>>> WSO2 Inc. http://wso2.com >>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>> >>>> <+94%2071%20411%205032> >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> Sathya Bandara >> Software Engineer >> WSO2 Inc. http://wso2.com >> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >> >> <+94%2071%20411%205032> >> > > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
