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 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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
