Hi all,
On Mon, Sep 11, 2017 at 11:28 AM, Dulanja Liyanage <dula...@wso2.com> wrote: > > > 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. > +1 IMO to make this role more flexible following things should be enforced; 1. Should have a seperate permission for dashboard login. But it should allow only dashboard login nothing else. 2. For other admin services that can be invoked from the dashboard should have seperate set of fine grained permissions such that system administrator can revoke permission as necessary from that role to allow only a desired set of services. > >> 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 > > Thaks and Regards, Thilina. -- *Thilina Madumal* *Software Engineer | **WSO2* Email: thilina...@wso2.com Mobile: *+ <+94%2077%20767%201807>94 774553167* Web: <http://goog_716986954>http://wso2.com <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
