Hi Johann,
On Wed, Jun 27, 2018 at 8:52 AM Johann Nallathamby <joh...@wso2.com> wrote: > Hi IAM Team, > > I think the following limitation in the WSO2 IS is causing some major > usability issues. > > We have following views mainly where we display claims for a user: > 1. Admin user profile view in management console > 2. My user profile view in user portal > 3. Self sign-up view > > The way we select the claims shown in these views is based on a single > property which is "supported by default". This means that we can't control > the behavior of a claim individually for each of these views and causing > some major usability issues. This also means that to get that experience > users have to do JSP customization to the product which I think we can > easily avoid. And when it comes to IDaaS, customization is not a choice. > > For example a claim like "Account Locked" has to be shown in "admin user > profile" view, but not for "self sign-up" view or "my user profile" view. > Also there can be a use case where I want to show minimal vital information > on the self sign-up page to make it easier for the user to sign-up, but > have an extensive profile view in the user portal. > > I faced these issues when trying to demo the product to customers, where > when I want to show the self sign-up flow with email verification, I enable > to "supported by default" property for "account locked" claim to show in > the "admin user profile" view that the account is actually getting locked > once the user signs up and until he confirms the email. But while doing > that the claim also gets visible in the "self sign-up" view that makes no > sense. > > We in fact have the capability to configure properties for each claim from > IS 5.3.0 onwards. This issue explained in this mail was actually one of the > reasons we added this capability to IS 5.3.0, but later it got diluted due > to IS 6.0.0 efforts. Can we introduce some new claim properties for the 3 > profiles above to control the visibility of the claims individually for > each of these views? > > We can easily do this without breaking backward compatibility. Since these > properties can be added through the claim management UI, we can even fix > the existing product versions in this way. We can continue to use the > "supported by default" property as the default property to fallback on if > the relevant new property is not configured. But if a user explicitly > configures this property we can use it. For the new versions we can ship > these properties with default values we agree on (may be not for all > claims, but the most important ones only, and for the rest the users can > explicitly create the properties through the UI). > Thanks for bringing this up. We will add this capability in a future release. [1] [1] https://github.com/wso2/product-is/issues/3412 Thanks Isura. > Thanks and Regards, > Johann. > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile: *+94 77 7776950* > LinkedIn: *http://www.linkedin.com/in/johann-nallathamby > <http://www.linkedin.com/in/johann-nallathamby>* > Medium: *https://medium.com/@johann_nallathamby > <https://medium.com/@johann_nallathamby>* > Twitter: *@dj_nallaa* > -- *Isura Dilhara Karunaratne* Associate Technical Lead | WSO2 <http://wso2.com/> *lean.enterprise.middleware* Email: is...@wso2.com Mob : +94 772 254 810 Blog : http://isurad.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
