On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna <isha...@wso2.com> wrote:
> HI, > > On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby <joh...@wso2.com> > wrote: > >> IAM Team, >> >> Currently we don't have a exclusive permission to login to the user >> portal; we use "/permission/admin/login". I think we need to have a >> dedicated permission for that. Why? >> >> 1. No way to allow users to login to user portal but restrict users from >> logging in to management console. >> >> 2. We could give this new permission to "INTERNAL/everyone" role. So that >> any new users added to the system, via admin console, SCIM, Self sign-up or >> JIT provisioning, will be able to login to the user portal. If we don't >> want that we can simply take off that permission from the >> "INTERNAL/everyone" role. >> >> I could think of further improving 2 above, by having separate roles for >> each of the following scenarios. >> a) Admin created users (Resident SP) - one role for all >> b) JIT provisioned users - one role per IdP >> c) Self signup users - we already have "selfsignup" role from IS >> 5.3.0 onwards. >> d) External service provider created users via SCIM - one role per SP >> All the above roles can have the new permission, and selectively taken >> off if not needed. In addition we can use these roles to manage permissions >> for these well known groups of users who came from the same source. >> >> I stumbled upon this issue when I was trying to do "Email verification >> and password request" scenario. Once I click the link in the email that was >> sent to my inbox, and confirm, and update my new password and confirm it, I >> was sent to the user portal to login. But since I didn't have the required >> authorization setup I failed to login. Bit of a bad user experience there. >> >> Shall we try to introduce a new permission for user portal and give it by >> default to "INTERNAL/everyone" for IS 5.4.0? >> > -1 for giving permission to "INTERNAL/everyone" > INTERNAL/everyone is a virtual Role that used to represent all users. for > example all the federated users also considered as users in > INTERNAL/everyone Role. > > Yes, me too -1 for using "INTERNAL/everyone" for this. > But agree with johan for having different permission for dashboard login. > And better if system admin do it manually. > I don't think this should be a manual task, because it will be tedious. IMO there should be a separate dedicated role to access the Dashboard with the new permission as mentioned by Johann - like the Subscriber role in AM - and in the user provisioning points, new users should be automatically added to that role depending on some configuration done by the admin. > And there is another concern with the permission, from the dashboard we > are invoking several admin services so those services also should work > with this new permission. > > Thanks, > Ishara > > >> Thanks & Regards, >> Johann. >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: > +94717996791 <071%20799%206791> > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Dulanja Liyanage Lead, Platform Security Team WSO2 Inc.
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
