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.
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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
