On Tue, Jul 4, 2017 at 9:59 AM, Hasintha Indrajee <[email protected]> wrote:
> We will be maintaining user store property to indicate whether the user > store supports claim operations (There may be multiple operation types, but > in this case claim operations). Before setting claims in pre and post > authentication listeners we will check whether the underlying user store is > supported for claim operations and will only continue if it's supported. > Unless returns and continues the flow. > +1. I think this may be the best way as of now. > > There were few options discussed > > 1) We can just turn off these event handlers which get fired on > authentication events. But we may only need to skip a specific user store > and we may still need to use identity management functionality with rest of > the user stores. In this case we have to introduce a user tore level > property/configuration. > > 2) One of the other options is to expect a predefined run time exception > from the methods which are not implemented in User Store Manager level and > handle them at our event handlers so that it will not have an effect on the > rest of the flow since we handle the run time exception. We thought of not > going with this since altering logic and taking decisions based on the type > of exception and error messages is not a good practice. > > > 3) Another possibility was to introduce above check (checking newly > introduced user store property and skipping) at the > IdentityMgtEventListener level so that none of the handlers will be fired > if the user store is not supported for that particular operation. This is > not a proper fix since we may still need to get events to event handler > level even if the user store is not supported certain operations. eg - Even > though the user store is not supported for claim operations the deployment > may be using JDBC based Identity Store. In that we don't need handlers to > be skipped. > > Hence the best option seems to be handling the behaviour based on newly > introduced property at specific concrete handler level. Depending on the > logic of specific handler it will decide whether to handle this event or > skip and continue. > > On Tue, Jul 4, 2017 at 9:35 AM, Sagara Gunathunga <[email protected]> wrote: > >> >> Hasintha, could you please update the thread with the solution we agreed >> ? >> >> >> Thanks ! >> >> On Wed, Jun 21, 2017 at 1:01 PM, Isura Karunaratne <[email protected]> >> wrote: >> >>> Hi >>> >>> On Wed, Jun 21, 2017 at 11:06 AM, Farasath Ahamed <[email protected]> >>> wrote: >>> >>>> >>>> >>>> >>>> >>>> On Wed, Jun 21, 2017 at 11:03 AM, Isura Karunaratne <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 20, 2017 at 11:29 PM, Johann Nallathamby <[email protected]> >>>>> wrote: >>>>> >>>>>> If these two handlers are disabled by default there shouldn't be any >>>>>> problem. According to default identity-event.properties file they are >>>>>> disabled. How come they get triggered then? >>>>>> >>>>> >>>>> Yes. By default the account lock/disabled features are disabled. If it >>>>> is required to use account lock/disable features, there should be a way to >>>>> store user properties. >>>>> >>>> >>>> Looks like we haven't used the property to check whether the listener >>>> is enabled or disabled although we have defined in >>>> identity-event.properties. Therefore the handlers get fired on >>>> pre-authentications >>>> >>> >>> Yes. This issue is fixed with https://wso2.org/jira/browse/IDENTITY-6091 >>> >>> Thanks >>> Isura. >>> >>>> >>>> >>>>> >>>>> Also, if the um_user_attribute table is not there, most of the use >>>>> cases will be broken. (Add User/ Update User/ Get Users ...). So, I think >>>>> that user store is incomplete. >>>>> >>>>> Thanks >>>>> Isura. >>>>> >>>>> >>>>>> >>>>>> On Tue, Jun 20, 2017 at 7:25 PM, Farasath Ahamed <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The minimum requirement to write a custom JDBC user store manager so >>>>>>> far (before IS 5.3.0) was to simply override the doAuthenticate() >>>>>>> method. >>>>>>> So a custom user store that was written for 5.0.0 worked without any >>>>>>> modifications (may be dependency changes). >>>>>>> >>>>>>> But when we use the same code on IS 5.3.0, the custom user store >>>>>>> implementations that only override the doAuthenticate() are broken >>>>>>> because >>>>>>> account disabled[1] and account locked[2] handlers introduced in IS >>>>>>> 5.3.0. >>>>>>> >>>>>>> These two handlers call the getUserClaimValues() method of the >>>>>>> userstore to retrieve some claims. Since we haven't overridden the >>>>>>> method >>>>>>> in custom userstore implementation it calls the super class. This leads >>>>>>> to >>>>>>> trying to find the claims from a non-existing table[3]. >>>>>>> >>>>>>> One way to solve is to override the getUserClaimValues() method. But >>>>>>> in the PoV of the extension developer, this would be an unnecessary >>>>>>> step if >>>>>>> the custom user store is just used for authentication only as explained >>>>>>> in >>>>>>> [4]. >>>>>>> >>>>>>> Even in the official docs[5], we do not have any mention of having >>>>>>> to implement the getUserClaimValues() method. >>>>>>> >>>>>>> What would be the correct and the most efficient way to resolve >>>>>>> this? >>>>>>> Appreciate your thoughts. >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/wso2-extensions/identity-event-handle >>>>>>> r-account-lock/blob/master/components/org.wso2.carbon.identi >>>>>>> ty.handler.event.account.lock/src/main/java/org/wso2/carbon/ >>>>>>> identity/handler/event/account/lock/AccountDisableHandler.java#L89 >>>>>>> >>>>>>> [2] https://github.com/wso2-extensions/identity-event-handle >>>>>>> r-account-lock/blob/master/components/org.wso2.carbon.identi >>>>>>> ty.handler.event.account.lock/src/main/java/org/wso2/carbon/ >>>>>>> identity/handler/event/account/lock/AccountLockHandler.java#L186 >>>>>>> >>>>>>> [3] https://wso2.org/jira/browse/IDENTITY-6074?focusedCommen >>>>>>> tId=134555&page=com.atlassian.jira.plugin.system.issuetabpan >>>>>>> els:comment-tabpanel#comment-134555 >>>>>>> >>>>>>> [4] https://wso2.org/jira/browse/IDENTITY-6074 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Farasath Ahamed >>>>>>> Software Engineer, WSO2 Inc.; http://wso2.com >>>>>>> Mobile: +94777603866 >>>>>>> Blog: blog.farazath.com >>>>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks & Regards, >>>>>> >>>>>> *Johann Dilantha Nallathamby* >>>>>> Senior Technical Lead - WSO2 Identity Server >>>>>> Governance Technologies Team >>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Isura Dilhara Karunaratne* >>>>> Senior Software Engineer | WSO2 >>>>> Email: [email protected] >>>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>>> Blog : http://isurad.blogspot.com/ >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> *Isura Dilhara Karunaratne* >>> Senior Software Engineer | WSO2 >>> Email: [email protected] >>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>> Blog : http://isurad.blogspot.com/ >>> >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Associate Director / Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> > > > -- > Hasintha Indrajee > WSO2, Inc. > Mobile:+94 771892453 <+94%2077%20189%202453> > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Technical Lead - WSO2 Identity Server Governance Technologies Team 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
