Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Asela Pathberiya]

On Mon, Sep 18, 2017 at 6:03 PM, Thilina Madumal 
wrote:

> Hi all,
>
>
> On Mon, Sep 11, 2017 at 11:28 AM, Dulanja Liyanage 
> wrote:
>
>>
>>
>> On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna 
>> wrote:
>>
>>> HI,
>>>
>>> On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby 
>>> 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.
>
>
Did we fix this in 5.4.0 ?

Is it by introducing a new role  ?   When user is self registered or
provisioned,  Is user default added in to this role ?

Thanks,
Asela.


>
>>
>>> 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 - *+9476950*
 Blog - *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: 

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Thilina Madumal]

Hi all,


On Mon, Sep 11, 2017 at 11:28 AM, Dulanja Liyanage  wrote:

>
>
> On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna 
> wrote:
>
>> HI,
>>
>> On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby 
>> 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 - *+9476950*
>>> Blog - *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://wso2.com


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Johann Nallathamby]

On Mon, Sep 11, 2017 at 11:28 AM, Dulanja Liyanage  wrote:

>
>
> On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna 
> wrote:
>
>> HI,
>>
>> On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby 
>> 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


>
>
>> 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 - *+9476950*
>>> Blog - *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.
>



-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Dulanja Liyanage]

On Mon, Sep 11, 2017 at 11:20 AM, Ishara Karunarathna 
wrote:

> HI,
>
> On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby 
> 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 - *+9476950*
>> Blog - *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

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Ishara Karunarathna]

HI,

On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby  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.

But agree with johan for having different permission for dashboard login.
And better if system admin do it manually.
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 - *+9476950*
> Blog - *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
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Can we have exclusive permission to login to user portal?

[Harsha Thirimanna]

On Fri, Sep 1, 2017 at 12:55 AM, Johann Nallathamby  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 this. We must address this for IS 5.4.0.
​
​https://wso2.org/jira/browse/IDENTITY-6390
​



>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture