On Tue, Mar 14, 2017 at 6:34 PM, Indunil Upeksha Rathnayake < [email protected]> wrote:
> > > On Tue, Mar 14, 2017 at 10:59 AM, Omindu Rathnaweera <[email protected]> > wrote: > >> >> >> On Tue, Mar 14, 2017 at 10:42 AM, Ayesha Dissanayaka <[email protected]> >> wrote: >> >>> >>> On Tue, Mar 14, 2017 at 10:18 AM, Denuwanthi De Silva < >>> [email protected]> wrote: >>> >>>> So, inorder to retrieve the type of onboarding we can set it as a >>>> property in the UserBean object. >>>> *Thus, we need to add a new property map attribute to the UserBean.* >>>> >>> >>> +1, I think introducing a new property map attribute to user bean will >>> have added values. >>> >> >> Worth mentioning that these properties will not get persisted. >> >> However, there's no direct way to send these properties through a SCIM >> request. correct ? >> > If necessary, I think that can be done with SCIM extensions. When adding > users through SCIM, we can add the on-boarding type through SCIM extension > attribute and in the back-end based on the passed value, we can include the > necessary property in UserBean. > Yes. Agree on this. However this cannot be done without code level changes in the SCIM implementation to set the properties to the userbean. In anycase, we have a limitation here that we cannot use the SCIM API for certain onboarding scenarios where we manage notifications internally since there's no way to return the confirmation codes generated in the handlers beyond the identity store operations (can use the same user bean properties but it's not the correct way to achieve this). We will need a proper solution which can cater both of these requirements; sending additional user properties to handlers and returning handler generated information outside the identity store operations. We'll have to think about something like passing a context as an input param for certain IdentityStore APIs. > > >> >>> >>> ex: When writing custom handlers , developers can pass some context >>> information within the user-bean so that looking at that handler logic can >>> be easily defined, thus improves handler implementation.(i.e. Client can >>> write his own handler to intercept user add scenario). >>> >>> Regards! >>> -Ayesha >>> >>> -- >>> *Ayesha Dissanayaka* >>> Senior Software Engineer, >>> WSO2, Inc : http://wso2.com >>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>> 20, Palm grove Avenue, Colombo 3 >>> E-Mail: [email protected] <[email protected]> >>> >> >> >> >> -- >> Omindu Rathnaweera >> Software Engineer, WSO2 Inc. >> Mobile: +94 771 197 211 <+94%2077%20119%207211> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email [email protected] > Mobile 0772182255 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > Regards, Omindu. -- Omindu Rathnaweera Software Engineer, WSO2 Inc. Mobile: +94 771 197 211 <+94%2077%20119%207211>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
