Re: [Architecture] [IS] Authorization for Service Providers

[Prabath Siriwardana]

Overall I think we need not to worry at this stage what happens from one
step to another. Authorization will happen at the end of the authentication
flow (as Pulasthi explained)... and SP should not be aware of what steps
got executed in the authentication flow - it will simply define access
control rule for that particular SP...

Thanks & regards,
-Prabath

On Wed, Oct 19, 2016 at 4:32 AM, Pulasthi Mahawithana 
wrote:

> Hi All,
>
>
>> Do we execute the authorization handler for each request...? even the
>> user is authenticated...?
>>
>
> Yes we do, that way we'll ensure that different policies will be evaluated
> per service provider even in the same IdP session. We also don't maintain
> an 'authorized' state for the user because it can change per SP. Even
> within the same SP the state may change on factors like time of day.
>
> On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal  wrote:
>>
>> As per my previous example, if authorization fails after first step
>>> (Basic authentication) we should not go for the next step and perform Fido
>>> authentication. right ?
>>
>>
>>> I am not quiet sure about the scope we are going to cover with this
>>> implement, Looks there are valid user cases as above.
>>
>> I think these are two use cases.
>>
>> 1. Authenticate the user with given authentication mechanism, once user
>>> is authenticated we check the users authorization.
>>
>> 2. Depend on users different authentication levels and associated
>>> authorization we change the users authentication flow.
>>
>>
>>> So in this implementation we are addressing 1st and later I think we can
>>> implement the option 2.
>>
>>
> Yes, for now we'll be addressing the case 1 only. The requirement
> mentioned by Eranga also falls to the option 2 here.
>
> On Wed, Oct 19, 2016 at 1:47 PM, Asela Pathberiya  wrote:
>
>>
>>
>> On Wed, Oct 19, 2016 at 12:57 PM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed 
>>> wrote:
>>>
 We also need to consider how we are going to handle the 'NotApplicable'
 and 'Indeterminate' responses by the XACML engine. Especially the
 Indeterminate response that might be due to some missing attributes etc.

 AFAIK the decisions of multiple evaluated policies are currently
 evaluated based on the combining algorithm (like Deny overrides, First
 applicable) defined globally.
 Shouldn't we also allow this algorithm to be decided at SP level?

>>> This is a good point. Policy combining algorithm is a global
>>> configuration that effect to all the available policies.
>>> since we are having different policy categories in the future we may
>>> need to set different policy combining algorithms to
>>> different policy categories.
>>> Until we implement we may have to live with that.
>>>
>> WDYT ?
>>>
>>
>> Yes. In SP level; we can define a policy set which contains multiple
>> policies & policy combining algo for that policy set...   But;  Yes. there
>> is a global policy combining algo which will effect for all the SP policy
>> set.  But; we can just filter out the requests for given SP by defining a
>> some specific value in target of the SP policy set (may be SP name).
>> Therefore;  we can avoid the effect from other SP policy set & global
>> policy algo (as there is only one policy set to combine)  Also;  Say;  we
>> need to enforce some rule for all the SPs. We can have a separate policy
>> set which will effect for all the SPs where global policy algo would be
>> useful..
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>



 Thanks,

 Farasath Ahamed
 Software Engineer, WSO2 Inc.; http://wso2.com
 Mobile: +94777603866
 Blog: blog.farazath.com
 Twitter: @farazath619 
 



 On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's
> authentication framework, it does not provide any OOTB authorization
> mechanism for the service providers. We are going to provide this
> capability to Identity server so that the users can be authorized to
> service providers using rules based on user attributes, userstore, time of
> the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the
> authentication steps are completed and authentication result decided. At
> the AuthenticationRequestHandler (after authentication) if the
> authentication is success, we will be calling an AuthorizationHandler with
> the authentication context. AuthenticationHandler is responsible for
> evaluating the configured policies and responding back 

Re: [Architecture] [IS] Authorization for Service Providers

[Pulasthi Mahawithana]

Hi All,


> Do we execute the authorization handler for each request...? even the user
> is authenticated...?
>

Yes we do, that way we'll ensure that different policies will be evaluated
per service provider even in the same IdP session. We also don't maintain
an 'authorized' state for the user because it can change per SP. Even
within the same SP the state may change on factors like time of day.

On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal  wrote:
>
> As per my previous example, if authorization fails after first step (Basic
>> authentication) we should not go for the next step and perform Fido
>> authentication. right ?
>
>
>> I am not quiet sure about the scope we are going to cover with this
>> implement, Looks there are valid user cases as above.
>
> I think these are two use cases.
>
> 1. Authenticate the user with given authentication mechanism, once user is
>> authenticated we check the users authorization.
>
> 2. Depend on users different authentication levels and associated
>> authorization we change the users authentication flow.
>
>
>> So in this implementation we are addressing 1st and later I think we can
>> implement the option 2.
>
>
Yes, for now we'll be addressing the case 1 only. The requirement mentioned
by Eranga also falls to the option 2 here.

On Wed, Oct 19, 2016 at 1:47 PM, Asela Pathberiya  wrote:

>
>
> On Wed, Oct 19, 2016 at 12:57 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Farasath,
>>
>> On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed 
>> wrote:
>>
>>> We also need to consider how we are going to handle the 'NotApplicable'
>>> and 'Indeterminate' responses by the XACML engine. Especially the
>>> Indeterminate response that might be due to some missing attributes etc.
>>>
>>> AFAIK the decisions of multiple evaluated policies are currently
>>> evaluated based on the combining algorithm (like Deny overrides, First
>>> applicable) defined globally.
>>> Shouldn't we also allow this algorithm to be decided at SP level?
>>>
>> This is a good point. Policy combining algorithm is a global
>> configuration that effect to all the available policies.
>> since we are having different policy categories in the future we may need
>> to set different policy combining algorithms to
>> different policy categories.
>> Until we implement we may have to live with that.
>>
> WDYT ?
>>
>
> Yes. In SP level; we can define a policy set which contains multiple
> policies & policy combining algo for that policy set...   But;  Yes. there
> is a global policy combining algo which will effect for all the SP policy
> set.  But; we can just filter out the requests for given SP by defining a
> some specific value in target of the SP policy set (may be SP name).
> Therefore;  we can avoid the effect from other SP policy set & global
> policy algo (as there is only one policy set to combine)  Also;  Say;  we
> need to enforce some rule for all the SPs. We can have a separate policy
> set which will effect for all the SPs where global policy algo would be
> useful..
>
> Thanks,
> Asela.
>
>
>>
>>
>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>
 Hi All,

 As per the current implementation of the Identity Server's
 authentication framework, it does not provide any OOTB authorization
 mechanism for the service providers. We are going to provide this
 capability to Identity server so that the users can be authorized to
 service providers using rules based on user attributes, userstore, time of
 the day, etc.

 Following is the proposed sequence for the implementation.


 [image: Inline image 1]


 The existing authentication flow is kept as is until the authentication
 steps are completed and authentication result decided. At the
 AuthenticationRequestHandler (after authentication) if the authentication
 is success, we will be calling an AuthorizationHandler with the
 authentication context. AuthenticationHandler is responsible for evaluating
 the configured policies and responding back whether the user is authorized
 or not. If the authorization is not required or handled by the SP
 itself, we'll be providing the capability of bypassing the authorization
 step per service provider .

 The default implementation of the AuthorizationHandler will be using
 the IS's XACML engine for authorization. It will send a XACML request to
 the PDP and the request will be evaluated against the policies published to
 the PDP. Admins can write XACML policies and publish them to allow/deny the
 users logging into SPs based on those 

Re: [Architecture] [IS] Authorization for Service Providers

[Asela Pathberiya]

On Wed, Oct 19, 2016 at 12:57 PM, Ishara Karunarathna 
wrote:

> Hi Farasath,
>
> On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed 
> wrote:
>
>> We also need to consider how we are going to handle the 'NotApplicable'
>> and 'Indeterminate' responses by the XACML engine. Especially the
>> Indeterminate response that might be due to some missing attributes etc.
>>
>> AFAIK the decisions of multiple evaluated policies are currently
>> evaluated based on the combining algorithm (like Deny overrides, First
>> applicable) defined globally.
>> Shouldn't we also allow this algorithm to be decided at SP level?
>>
> This is a good point. Policy combining algorithm is a global configuration
> that effect to all the available policies.
> since we are having different policy categories in the future we may need
> to set different policy combining algorithms to
> different policy categories.
> Until we implement we may have to live with that.
>
WDYT ?
>

Yes. In SP level; we can define a policy set which contains multiple
policies & policy combining algo for that policy set...   But;  Yes. there
is a global policy combining algo which will effect for all the SP policy
set.  But; we can just filter out the requests for given SP by defining a
some specific value in target of the SP policy set (may be SP name).
Therefore;  we can avoid the effect from other SP policy set & global
policy algo (as there is only one policy set to combine)  Also;  Say;  we
need to enforce some rule for all the SPs. We can have a separate policy
set which will effect for all the SPs where global policy algo would be
useful..

Thanks,
Asela.


>
>
>
>>
>>
>>
>> Thanks,
>>
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana > > wrote:
>>
>>> Hi All,
>>>
>>> As per the current implementation of the Identity Server's
>>> authentication framework, it does not provide any OOTB authorization
>>> mechanism for the service providers. We are going to provide this
>>> capability to Identity server so that the users can be authorized to
>>> service providers using rules based on user attributes, userstore, time of
>>> the day, etc.
>>>
>>> Following is the proposed sequence for the implementation.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The existing authentication flow is kept as is until the authentication
>>> steps are completed and authentication result decided. At the
>>> AuthenticationRequestHandler (after authentication) if the authentication
>>> is success, we will be calling an AuthorizationHandler with the
>>> authentication context. AuthenticationHandler is responsible for evaluating
>>> the configured policies and responding back whether the user is authorized
>>> or not. If the authorization is not required or handled by the SP
>>> itself, we'll be providing the capability of bypassing the authorization
>>> step per service provider .
>>>
>>> The default implementation of the AuthorizationHandler will be using the
>>> IS's XACML engine for authorization. It will send a XACML request to the
>>> PDP and the request will be evaluated against the policies published to the
>>> PDP. Admins can write XACML policies and publish them to allow/deny the
>>> users logging into SPs based on those policies.
>>>
>>> Also, to retrieve the basic authentication context values (such as SP
>>> Name, authenticated user's username/userstore/tenant) we will provide a
>>> default PIP. In case any complex or derived attributes are needed we can
>>> retrieve them by writing a custom PIP and use them in the policies.
>>>
>>> Please share your thoughts and suggestions.
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: http://blog.pulasthi.org
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791
>
>
>


-- 
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
 +358 449 228 979

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

Re: [Architecture] [IS] Authorization for Service Providers

[Ishara Karunarathna]

Hi Farasath,

On Wed, Oct 19, 2016 at 12:39 PM, Farasath Ahamed 
wrote:

> We also need to consider how we are going to handle the 'NotApplicable'
> and 'Indeterminate' responses by the XACML engine. Especially the
> Indeterminate response that might be due to some missing attributes etc.
>
> AFAIK the decisions of multiple evaluated policies are currently evaluated
> based on the combining algorithm (like Deny overrides, First applicable)
> defined globally.
> Shouldn't we also allow this algorithm to be decided at SP level?
>
This is a good point. Policy combining algorithm is a global configuration
that effect to all the available policies.
since we are having different policy categories in the future we may need
to set different policy combining algorithms to
different policy categories.
Until we implement we may have to live with that.
WDYT ?



>
>
>
> Thanks,
>
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana 
> wrote:
>
>> Hi All,
>>
>> As per the current implementation of the Identity Server's authentication
>> framework, it does not provide any OOTB authorization mechanism for the
>> service providers. We are going to provide this capability to Identity
>> server so that the users can be authorized to service providers using rules
>> based on user attributes, userstore, time of the day, etc.
>>
>> Following is the proposed sequence for the implementation.
>>
>>
>> [image: Inline image 1]
>>
>>
>> The existing authentication flow is kept as is until the authentication
>> steps are completed and authentication result decided. At the
>> AuthenticationRequestHandler (after authentication) if the authentication
>> is success, we will be calling an AuthorizationHandler with the
>> authentication context. AuthenticationHandler is responsible for evaluating
>> the configured policies and responding back whether the user is authorized
>> or not. If the authorization is not required or handled by the SP
>> itself, we'll be providing the capability of bypassing the authorization
>> step per service provider .
>>
>> The default implementation of the AuthorizationHandler will be using the
>> IS's XACML engine for authorization. It will send a XACML request to the
>> PDP and the request will be evaluated against the policies published to the
>> PDP. Admins can write XACML policies and publish them to allow/deny the
>> users logging into SPs based on those policies.
>>
>> Also, to retrieve the basic authentication context values (such as SP
>> Name, authenticated user's username/userstore/tenant) we will provide a
>> default PIP. In case any complex or derived attributes are needed we can
>> retrieve them by writing a custom PIP and use them in the policies.
>>
>> Please share your thoughts and suggestions.
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
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] [IS] Authorization for Service Providers

[Farasath Ahamed]

We also need to consider how we are going to handle the 'NotApplicable' and
'Indeterminate' responses by the XACML engine. Especially the Indeterminate
response that might be due to some missing attributes etc.

AFAIK the decisions of multiple evaluated policies are currently evaluated
based on the combining algorithm (like Deny overrides, First applicable)
defined globally.
Shouldn't we also allow this algorithm to be decided at SP level?



Thanks,

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 




On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana 
wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's authentication
> framework, it does not provide any OOTB authorization mechanism for the
> service providers. We are going to provide this capability to Identity
> server so that the users can be authorized to service providers using rules
> based on user attributes, userstore, time of the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the authentication
> steps are completed and authentication result decided. At the
> AuthenticationRequestHandler (after authentication) if the authentication
> is success, we will be calling an AuthorizationHandler with the
> authentication context. AuthenticationHandler is responsible for evaluating
> the configured policies and responding back whether the user is authorized
> or not. If the authorization is not required or handled by the SP
> itself, we'll be providing the capability of bypassing the authorization
> step per service provider .
>
> The default implementation of the AuthorizationHandler will be using the
> IS's XACML engine for authorization. It will send a XACML request to the
> PDP and the request will be evaluated against the policies published to the
> PDP. Admins can write XACML policies and publish them to allow/deny the
> users logging into SPs based on those policies.
>
> Also, to retrieve the basic authentication context values (such as SP
> Name, authenticated user's username/userstore/tenant) we will provide a
> default PIP. In case any complex or derived attributes are needed we can
> retrieve them by writing a custom PIP and use them in the policies.
>
> Please share your thoughts and suggestions.
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Ishara Karunarathna]

Hi Godwin,

On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal  wrote:

> As per my previous example, if authorization fails after first step (Basic
> authentication) we should not go for the next step and perform Fido
> authentication. right ?
>
> I am not quiet sure about the scope we are going to cover with this
> implement, Looks there are valid user cases as above.
>
I think these are two use cases.
1. Authenticate the user with given authentication mechanism, once user is
authenticated we check the users authorization.
2. Depend on users different authentication levels and associated
authorization we change the users authentication flow.

So in this implementation we are addressing 1st and later I think we can
implement the option 2.

-Ishara

>
>
> Thanks
> Godwin
>
>
> On Wed, Oct 19, 2016 at 9:56 AM, Harsha Thirimanna 
> wrote:
>
>> As in sequence diagram, we can't do that, and actually do we need that
>> level ?
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead | WSO2
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>> On Wed, Oct 19, 2016 at 9:51 AM, Godwin Shrimal  wrote:
>>
>>> How can we attach authorization handlers in steps level with the current
>>> design ?
>>>
>>> Ex.
>>> Step1 : Do basic authentication
>>> Step2 : Perform authorization for above authenticated user
>>> Step3 : Perform Fido authentication
>>>
>>> In that case don’t we need to handle it in Step level ? same as how we
>>> handle Authenticators  ?
>>>
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>
 Hi All,

 As per the current implementation of the Identity Server's
 authentication framework, it does not provide any OOTB authorization
 mechanism for the service providers. We are going to provide this
 capability to Identity server so that the users can be authorized to
 service providers using rules based on user attributes, userstore, time of
 the day, etc.

 Following is the proposed sequence for the implementation.


 [image: Inline image 1]


 The existing authentication flow is kept as is until the authentication
 steps are completed and authentication result decided. At the
 AuthenticationRequestHandler (after authentication) if the authentication
 is success, we will be calling an AuthorizationHandler with the
 authentication context. AuthenticationHandler is responsible for evaluating
 the configured policies and responding back whether the user is authorized
 or not. If the authorization is not required or handled by the SP
 itself, we'll be providing the capability of bypassing the authorization
 step per service provider .

 The default implementation of the AuthorizationHandler will be using
 the IS's XACML engine for authorization. It will send a XACML request to
 the PDP and the request will be evaluated against the policies published to
 the PDP. Admins can write XACML policies and publish them to allow/deny the
 users logging into SPs based on those policies.

 Also, to retrieve the basic authentication context values (such as SP
 Name, authenticated user's username/userstore/tenant) we will provide a
 default PIP. In case any complex or derived attributes are needed we can
 retrieve them by writing a custom PIP and use them in the policies.

 Please share your thoughts and suggestions.

 --
 *Pulasthi Mahawithana*
 Senior Software Engineer
 WSO2 Inc., http://wso2.com/
 Mobile: +94-71-5179022
 Blog: http://blog.pulasthi.org

 

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


>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D *
>>> twitter: https://twitter.com/godwinamila
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D 

Re: [Architecture] [IS] Authorization for Service Providers

[Eranga Perera]

Hi,

Another requirement I have seen is to have a set of authentication levels
and depending on the required level present a different combinations of
authenticator steps for authentication.
For instance initially a user may be required to authenticated with only
basic the authenticator which will be categorized as basic (or level 1) and
when needs to perform a
privileged action/operation in the application the SP might decide that
current login level is inadequate and will redirect to user to Identity
server to obtain a higher authentication
level (Say level 2 or strongly authenticated), where the user will be
challenged with a set of authenticators from multi-factor steps. the
stepping up of authentication level can be
temporary or permanent for the session.

Eranga.

On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal  wrote:

> As per my previous example, if authorization fails after first step (Basic
> authentication) we should not go for the next step and perform Fido
> authentication. right ?
>
> I am not quiet sure about the scope we are going to cover with this
> implement, Looks there are valid user cases as above.
>
>
> Thanks
> Godwin
>
>
> On Wed, Oct 19, 2016 at 9:56 AM, Harsha Thirimanna 
> wrote:
>
>> As in sequence diagram, we can't do that, and actually do we need that
>> level ?
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead | WSO2
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>> On Wed, Oct 19, 2016 at 9:51 AM, Godwin Shrimal  wrote:
>>
>>> How can we attach authorization handlers in steps level with the current
>>> design ?
>>>
>>> Ex.
>>> Step1 : Do basic authentication
>>> Step2 : Perform authorization for above authenticated user
>>> Step3 : Perform Fido authentication
>>>
>>> In that case don’t we need to handle it in Step level ? same as how we
>>> handle Authenticators  ?
>>>
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>
 Hi All,

 As per the current implementation of the Identity Server's
 authentication framework, it does not provide any OOTB authorization
 mechanism for the service providers. We are going to provide this
 capability to Identity server so that the users can be authorized to
 service providers using rules based on user attributes, userstore, time of
 the day, etc.

 Following is the proposed sequence for the implementation.


 [image: Inline image 1]


 The existing authentication flow is kept as is until the authentication
 steps are completed and authentication result decided. At the
 AuthenticationRequestHandler (after authentication) if the authentication
 is success, we will be calling an AuthorizationHandler with the
 authentication context. AuthenticationHandler is responsible for evaluating
 the configured policies and responding back whether the user is authorized
 or not. If the authorization is not required or handled by the SP
 itself, we'll be providing the capability of bypassing the authorization
 step per service provider .

 The default implementation of the AuthorizationHandler will be using
 the IS's XACML engine for authorization. It will send a XACML request to
 the PDP and the request will be evaluated against the policies published to
 the PDP. Admins can write XACML policies and publish them to allow/deny the
 users logging into SPs based on those policies.

 Also, to retrieve the basic authentication context values (such as SP
 Name, authenticated user's username/userstore/tenant) we will provide a
 default PIP. In case any complex or derived attributes are needed we can
 retrieve them by writing a custom PIP and use them in the policies.

 Please share your thoughts and suggestions.

 --
 *Pulasthi Mahawithana*
 Senior Software Engineer
 WSO2 Inc., http://wso2.com/
 Mobile: +94-71-5179022
 Blog: http://blog.pulasthi.org

 

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


>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Senior Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D *
>>> twitter: https://twitter.com/godwinamila
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> 

Re: [Architecture] [IS] Authorization for Service Providers

[Godwin Shrimal]

As per my previous example, if authorization fails after first step (Basic
authentication) we should not go for the next step and perform Fido
authentication. right ?

I am not quiet sure about the scope we are going to cover with this
implement, Looks there are valid user cases as above.


Thanks
Godwin


On Wed, Oct 19, 2016 at 9:56 AM, Harsha Thirimanna  wrote:

> As in sequence diagram, we can't do that, and actually do we need that
> level ?
>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> 
>
> On Wed, Oct 19, 2016 at 9:51 AM, Godwin Shrimal  wrote:
>
>> How can we attach authorization handlers in steps level with the current
>> design ?
>>
>> Ex.
>> Step1 : Do basic authentication
>> Step2 : Perform authorization for above authenticated user
>> Step3 : Perform Fido authentication
>>
>> In that case don’t we need to handle it in Step level ? same as how we
>> handle Authenticators  ?
>>
>>
>>
>> Thanks
>> Godwin
>>
>> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana > > wrote:
>>
>>> Hi All,
>>>
>>> As per the current implementation of the Identity Server's
>>> authentication framework, it does not provide any OOTB authorization
>>> mechanism for the service providers. We are going to provide this
>>> capability to Identity server so that the users can be authorized to
>>> service providers using rules based on user attributes, userstore, time of
>>> the day, etc.
>>>
>>> Following is the proposed sequence for the implementation.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The existing authentication flow is kept as is until the authentication
>>> steps are completed and authentication result decided. At the
>>> AuthenticationRequestHandler (after authentication) if the authentication
>>> is success, we will be calling an AuthorizationHandler with the
>>> authentication context. AuthenticationHandler is responsible for evaluating
>>> the configured policies and responding back whether the user is authorized
>>> or not. If the authorization is not required or handled by the SP
>>> itself, we'll be providing the capability of bypassing the authorization
>>> step per service provider .
>>>
>>> The default implementation of the AuthorizationHandler will be using the
>>> IS's XACML engine for authorization. It will send a XACML request to the
>>> PDP and the request will be evaluated against the policies published to the
>>> PDP. Admins can write XACML policies and publish them to allow/deny the
>>> users logging into SPs based on those policies.
>>>
>>> Also, to retrieve the basic authentication context values (such as SP
>>> Name, authenticated user's username/userstore/tenant) we will provide a
>>> default PIP. In case any complex or derived attributes are needed we can
>>> retrieve them by writing a custom PIP and use them in the policies.
>>>
>>> Please share your thoughts and suggestions.
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: http://blog.pulasthi.org
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Godwin Amila Shrimal*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94772264165*
>> linkedin: *http://lnkd.in/KUum6D *
>> twitter: https://twitter.com/godwinamila
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

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

Re: [Architecture] [IS] Authorization for Service Providers

[Harsha Thirimanna]

As in sequence diagram, we can't do that, and actually do we need that
level ?

*Harsha Thirimanna*
Associate Tech Lead | WSO2

Email: hars...@wso2.com
Mob: +94715186770
Blog: http://harshathirimanna.blogspot.com/
Twitter: http://twitter.com/harshathirimann
Linked-In: linked-in:
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122


On Wed, Oct 19, 2016 at 9:51 AM, Godwin Shrimal  wrote:

> How can we attach authorization handlers in steps level with the current
> design ?
>
> Ex.
> Step1 : Do basic authentication
> Step2 : Perform authorization for above authenticated user
> Step3 : Perform Fido authentication
>
> In that case don’t we need to handle it in Step level ? same as how we
> handle Authenticators  ?
>
>
>
> Thanks
> Godwin
>
> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana 
> wrote:
>
>> Hi All,
>>
>> As per the current implementation of the Identity Server's authentication
>> framework, it does not provide any OOTB authorization mechanism for the
>> service providers. We are going to provide this capability to Identity
>> server so that the users can be authorized to service providers using rules
>> based on user attributes, userstore, time of the day, etc.
>>
>> Following is the proposed sequence for the implementation.
>>
>>
>> [image: Inline image 1]
>>
>>
>> The existing authentication flow is kept as is until the authentication
>> steps are completed and authentication result decided. At the
>> AuthenticationRequestHandler (after authentication) if the authentication
>> is success, we will be calling an AuthorizationHandler with the
>> authentication context. AuthenticationHandler is responsible for evaluating
>> the configured policies and responding back whether the user is authorized
>> or not. If the authorization is not required or handled by the SP
>> itself, we'll be providing the capability of bypassing the authorization
>> step per service provider .
>>
>> The default implementation of the AuthorizationHandler will be using the
>> IS's XACML engine for authorization. It will send a XACML request to the
>> PDP and the request will be evaluated against the policies published to the
>> PDP. Admins can write XACML policies and publish them to allow/deny the
>> users logging into SPs based on those policies.
>>
>> Also, to retrieve the basic authentication context values (such as SP
>> Name, authenticated user's username/userstore/tenant) we will provide a
>> default PIP. In case any complex or derived attributes are needed we can
>> retrieve them by writing a custom PIP and use them in the policies.
>>
>> Please share your thoughts and suggestions.
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Prabath Siriwardana]

I think we need not to worry about it as we have the PDP decision caching -
we can just talk to the PDP each time...

Thanks & regards,
-Prabath

On Wed, Oct 19, 2016 at 12:15 AM, Harsha Thirimanna 
wrote:

> So, can't we keep the status 'authorized' with the SP name as well.
>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> 
>
> On Wed, Oct 19, 2016 at 9:40 AM, Prabath Siriwardana 
> wrote:
>
>> It can change - you can authenticate a user with foo SP and then you will
>> be authenticated automatically for bar SP - but they may have different
>> authorization policies...
>>
>> Thanks & regards,
>> -Prabath
>>
>>
>> On Wed, Oct 19, 2016 at 12:01 AM, Harsha Thirimanna 
>> wrote:
>>
>>> I think , it doesn't matter to hit the authorization handler each time,
>>> if we can keep the status as user 'authorized'  as same as we keep user
>>> 'authenticated'  in each steps.
>>>
>>> *Harsha Thirimanna*
>>> Associate Tech Lead | WSO2
>>>
>>> Email: hars...@wso2.com
>>> Mob: +94715186770
>>> Blog: http://harshathirimanna.blogspot.com/
>>> Twitter: http://twitter.com/harshathirimann
>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>>> rsha-thirimanna/10/ab8/122
>>> 
>>>
>>> On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana 
>>> wrote:
>>>
 Do we execute the authorization handler for each request...? even the
 user is authenticated...?

 Thanks & regards,
 -Prabath

 On Tue, Oct 18, 2016 at 3:50 PM, Pulasthi Mahawithana <
 pulast...@wso2.com> wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's
> authentication framework, it does not provide any OOTB authorization
> mechanism for the service providers. We are going to provide this
> capability to Identity server so that the users can be authorized to
> service providers using rules based on user attributes, userstore, time of
> the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the
> authentication steps are completed and authentication result decided. At
> the AuthenticationRequestHandler (after authentication) if the
> authentication is success, we will be calling an AuthorizationHandler with
> the authentication context. AuthenticationHandler is responsible for
> evaluating the configured policies and responding back whether the user is
> authorized or not. If the authorization is not required or handled by the
> SP itself, we'll be providing the capability of bypassing the 
> authorization
> step per service provider .
>
> The default implementation of the AuthorizationHandler will be using
> the IS's XACML engine for authorization. It will send a XACML request to
> the PDP and the request will be evaluated against the policies published 
> to
> the PDP. Admins can write XACML policies and publish them to allow/deny 
> the
> users logging into SPs based on those policies.
>
> Also, to retrieve the basic authentication context values (such as SP
> Name, authenticated user's username/userstore/tenant) we will provide a
> default PIP. In case any complex or derived attributes are needed we can
> retrieve them by writing a custom PIP and use them in the policies.
>
> Please share your thoughts and suggestions.
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> 
>



 --
 Thanks & Regards,
 Prabath

 Twitter : @prabath
 LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

 Mobile : +1 650 625 7950

 http://facilelogin.com

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


>>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +1 650 625 7950
>>
>> http://facilelogin.com
>>
>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] [IS] Authorization for Service Providers

[Harsha Thirimanna]

So, can't we keep the status 'authorized' with the SP name as well.

*Harsha Thirimanna*
Associate Tech Lead | WSO2

Email: hars...@wso2.com
Mob: +94715186770
Blog: http://harshathirimanna.blogspot.com/
Twitter: http://twitter.com/harshathirimann
Linked-In: linked-in:
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122


On Wed, Oct 19, 2016 at 9:40 AM, Prabath Siriwardana 
wrote:

> It can change - you can authenticate a user with foo SP and then you will
> be authenticated automatically for bar SP - but they may have different
> authorization policies...
>
> Thanks & regards,
> -Prabath
>
>
> On Wed, Oct 19, 2016 at 12:01 AM, Harsha Thirimanna 
> wrote:
>
>> I think , it doesn't matter to hit the authorization handler each time,
>> if we can keep the status as user 'authorized'  as same as we keep user
>> 'authenticated'  in each steps.
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead | WSO2
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770
>> Blog: http://harshathirimanna.blogspot.com/
>> Twitter: http://twitter.com/harshathirimann
>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>> rsha-thirimanna/10/ab8/122
>> 
>>
>> On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana 
>> wrote:
>>
>>> Do we execute the authorization handler for each request...? even the
>>> user is authenticated...?
>>>
>>> Thanks & regards,
>>> -Prabath
>>>
>>> On Tue, Oct 18, 2016 at 3:50 PM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>
 Hi All,

 As per the current implementation of the Identity Server's
 authentication framework, it does not provide any OOTB authorization
 mechanism for the service providers. We are going to provide this
 capability to Identity server so that the users can be authorized to
 service providers using rules based on user attributes, userstore, time of
 the day, etc.

 Following is the proposed sequence for the implementation.


 [image: Inline image 1]


 The existing authentication flow is kept as is until the authentication
 steps are completed and authentication result decided. At the
 AuthenticationRequestHandler (after authentication) if the authentication
 is success, we will be calling an AuthorizationHandler with the
 authentication context. AuthenticationHandler is responsible for evaluating
 the configured policies and responding back whether the user is authorized
 or not. If the authorization is not required or handled by the SP
 itself, we'll be providing the capability of bypassing the authorization
 step per service provider .

 The default implementation of the AuthorizationHandler will be using
 the IS's XACML engine for authorization. It will send a XACML request to
 the PDP and the request will be evaluated against the policies published to
 the PDP. Admins can write XACML policies and publish them to allow/deny the
 users logging into SPs based on those policies.

 Also, to retrieve the basic authentication context values (such as SP
 Name, authenticated user's username/userstore/tenant) we will provide a
 default PIP. In case any complex or derived attributes are needed we can
 retrieve them by writing a custom PIP and use them in the policies.

 Please share your thoughts and suggestions.

 --
 *Pulasthi Mahawithana*
 Senior Software Engineer
 WSO2 Inc., http://wso2.com/
 Mobile: +94-71-5179022
 Blog: http://blog.pulasthi.org

 

>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Prabath
>>>
>>> Twitter : @prabath
>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>>
>>> Mobile : +1 650 625 7950
>>>
>>> http://facilelogin.com
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://facilelogin.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Prabath Siriwardana]

It can change - you can authenticate a user with foo SP and then you will
be authenticated automatically for bar SP - but they may have different
authorization policies...

Thanks & regards,
-Prabath

On Wed, Oct 19, 2016 at 12:01 AM, Harsha Thirimanna 
wrote:

> I think , it doesn't matter to hit the authorization handler each time, if
> we can keep the status as user 'authorized'  as same as we keep user
> 'authenticated'  in each steps.
>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/ha
> rsha-thirimanna/10/ab8/122
> 
>
> On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana 
> wrote:
>
>> Do we execute the authorization handler for each request...? even the
>> user is authenticated...?
>>
>> Thanks & regards,
>> -Prabath
>>
>> On Tue, Oct 18, 2016 at 3:50 PM, Pulasthi Mahawithana > > wrote:
>>
>>> Hi All,
>>>
>>> As per the current implementation of the Identity Server's
>>> authentication framework, it does not provide any OOTB authorization
>>> mechanism for the service providers. We are going to provide this
>>> capability to Identity server so that the users can be authorized to
>>> service providers using rules based on user attributes, userstore, time of
>>> the day, etc.
>>>
>>> Following is the proposed sequence for the implementation.
>>>
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> The existing authentication flow is kept as is until the authentication
>>> steps are completed and authentication result decided. At the
>>> AuthenticationRequestHandler (after authentication) if the authentication
>>> is success, we will be calling an AuthorizationHandler with the
>>> authentication context. AuthenticationHandler is responsible for evaluating
>>> the configured policies and responding back whether the user is authorized
>>> or not. If the authorization is not required or handled by the SP
>>> itself, we'll be providing the capability of bypassing the authorization
>>> step per service provider .
>>>
>>> The default implementation of the AuthorizationHandler will be using the
>>> IS's XACML engine for authorization. It will send a XACML request to the
>>> PDP and the request will be evaluated against the policies published to the
>>> PDP. Admins can write XACML policies and publish them to allow/deny the
>>> users logging into SPs based on those policies.
>>>
>>> Also, to retrieve the basic authentication context values (such as SP
>>> Name, authenticated user's username/userstore/tenant) we will provide a
>>> default PIP. In case any complex or derived attributes are needed we can
>>> retrieve them by writing a custom PIP and use them in the policies.
>>>
>>> Please share your thoughts and suggestions.
>>>
>>> --
>>> *Pulasthi Mahawithana*
>>> Senior Software Engineer
>>> WSO2 Inc., http://wso2.com/
>>> Mobile: +94-71-5179022
>>> Blog: http://blog.pulasthi.org
>>>
>>> 
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Prabath
>>
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>>
>> Mobile : +1 650 625 7950
>>
>> http://facilelogin.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] [IS] Authorization for Service Providers

[Harsha Thirimanna]

I think , it doesn't matter to hit the authorization handler each time, if
we can keep the status as user 'authorized'  as same as we keep user
'authenticated'  in each steps.

*Harsha Thirimanna*
Associate Tech Lead | WSO2

Email: hars...@wso2.com
Mob: +94715186770
Blog: http://harshathirimanna.blogspot.com/
Twitter: http://twitter.com/harshathirimann
Linked-In: linked-in: http://www.linkedin.com/pub/
harsha-thirimanna/10/ab8/122


On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana 
wrote:

> Do we execute the authorization handler for each request...? even the user
> is authenticated...?
>
> Thanks & regards,
> -Prabath
>
> On Tue, Oct 18, 2016 at 3:50 PM, Pulasthi Mahawithana 
> wrote:
>
>> Hi All,
>>
>> As per the current implementation of the Identity Server's authentication
>> framework, it does not provide any OOTB authorization mechanism for the
>> service providers. We are going to provide this capability to Identity
>> server so that the users can be authorized to service providers using rules
>> based on user attributes, userstore, time of the day, etc.
>>
>> Following is the proposed sequence for the implementation.
>>
>>
>> [image: Inline image 1]
>>
>>
>> The existing authentication flow is kept as is until the authentication
>> steps are completed and authentication result decided. At the
>> AuthenticationRequestHandler (after authentication) if the authentication
>> is success, we will be calling an AuthorizationHandler with the
>> authentication context. AuthenticationHandler is responsible for evaluating
>> the configured policies and responding back whether the user is authorized
>> or not. If the authorization is not required or handled by the SP
>> itself, we'll be providing the capability of bypassing the authorization
>> step per service provider .
>>
>> The default implementation of the AuthorizationHandler will be using the
>> IS's XACML engine for authorization. It will send a XACML request to the
>> PDP and the request will be evaluated against the policies published to the
>> PDP. Admins can write XACML policies and publish them to allow/deny the
>> users logging into SPs based on those policies.
>>
>> Also, to retrieve the basic authentication context values (such as SP
>> Name, authenticated user's username/userstore/tenant) we will provide a
>> default PIP. In case any complex or derived attributes are needed we can
>> retrieve them by writing a custom PIP and use them in the policies.
>>
>> Please share your thoughts and suggestions.
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950
>
> http://facilelogin.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Authorization for Service Providers

[Prabath Siriwardana]

Do we execute the authorization handler for each request...? even the user
is authenticated...?

Thanks & regards,
-Prabath

On Tue, Oct 18, 2016 at 3:50 PM, Pulasthi Mahawithana 
wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's authentication
> framework, it does not provide any OOTB authorization mechanism for the
> service providers. We are going to provide this capability to Identity
> server so that the users can be authorized to service providers using rules
> based on user attributes, userstore, time of the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the authentication
> steps are completed and authentication result decided. At the
> AuthenticationRequestHandler (after authentication) if the authentication
> is success, we will be calling an AuthorizationHandler with the
> authentication context. AuthenticationHandler is responsible for evaluating
> the configured policies and responding back whether the user is authorized
> or not. If the authorization is not required or handled by the SP
> itself, we'll be providing the capability of bypassing the authorization
> step per service provider .
>
> The default implementation of the AuthorizationHandler will be using the
> IS's XACML engine for authorization. It will send a XACML request to the
> PDP and the request will be evaluated against the policies published to the
> PDP. Admins can write XACML policies and publish them to allow/deny the
> users logging into SPs based on those policies.
>
> Also, to retrieve the basic authentication context values (such as SP
> Name, authenticated user's username/userstore/tenant) we will provide a
> default PIP. In case any complex or derived attributes are needed we can
> retrieve them by writing a custom PIP and use them in the policies.
>
> Please share your thoughts and suggestions.
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> 
>



-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] [IS] Authorization for Service Providers

[Prabath Siriwardana]

On Tue, Oct 18, 2016 at 11:15 PM, Harsha Thirimanna 
wrote:

> ​Within the tenant story, when the SP is enable SAAS, is that possible to
> use logged in user's tenant specific XACML policy to use as authorization
> policy in above framework instead of using SP's tenant XACML policy ? ​
>

I think the authorization policy should come from SPs domain - SP defines
who can access it under which conditions...

Thanks & regards,
-Prabath


>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> 
>
> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana 
> wrote:
>
>> Hi All,
>>
>> As per the current implementation of the Identity Server's authentication
>> framework, it does not provide any OOTB authorization mechanism for the
>> service providers. We are going to provide this capability to Identity
>> server so that the users can be authorized to service providers using rules
>> based on user attributes, userstore, time of the day, etc.
>>
>> Following is the proposed sequence for the implementation.
>>
>>
>> [image: Inline image 1]
>>
>>
>> The existing authentication flow is kept as is until the authentication
>> steps are completed and authentication result decided. At the
>> AuthenticationRequestHandler (after authentication) if the authentication
>> is success, we will be calling an AuthorizationHandler with the
>> authentication context. AuthenticationHandler is responsible for evaluating
>> the configured policies and responding back whether the user is authorized
>> or not. If the authorization is not required or handled by the SP
>> itself, we'll be providing the capability of bypassing the authorization
>> step per service provider .
>>
>> The default implementation of the AuthorizationHandler will be using the
>> IS's XACML engine for authorization. It will send a XACML request to the
>> PDP and the request will be evaluated against the policies published to the
>> PDP. Admins can write XACML policies and publish them to allow/deny the
>> users logging into SPs based on those policies.
>>
>> Also, to retrieve the basic authentication context values (such as SP
>> Name, authenticated user's username/userstore/tenant) we will provide a
>> default PIP. In case any complex or derived attributes are needed we can
>> retrieve them by writing a custom PIP and use them in the policies.
>>
>> Please share your thoughts and suggestions.
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>


-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

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

Re: [Architecture] [IS] Authorization for Service Providers

[Harsha Thirimanna]

​Within the tenant story, when the SP is enable SAAS, is that possible to
use logged in user's tenant specific XACML policy to use as authorization
policy in above framework instead of using SP's tenant XACML policy ? ​

*Harsha Thirimanna*
Associate Tech Lead | WSO2

Email: hars...@wso2.com
Mob: +94715186770
Blog: http://harshathirimanna.blogspot.com/
Twitter: http://twitter.com/harshathirimann
Linked-In: linked-in:
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122


On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana 
wrote:

> Hi All,
>
> As per the current implementation of the Identity Server's authentication
> framework, it does not provide any OOTB authorization mechanism for the
> service providers. We are going to provide this capability to Identity
> server so that the users can be authorized to service providers using rules
> based on user attributes, userstore, time of the day, etc.
>
> Following is the proposed sequence for the implementation.
>
>
> [image: Inline image 1]
>
>
> The existing authentication flow is kept as is until the authentication
> steps are completed and authentication result decided. At the
> AuthenticationRequestHandler (after authentication) if the authentication
> is success, we will be calling an AuthorizationHandler with the
> authentication context. AuthenticationHandler is responsible for evaluating
> the configured policies and responding back whether the user is authorized
> or not. If the authorization is not required or handled by the SP
> itself, we'll be providing the capability of bypassing the authorization
> step per service provider .
>
> The default implementation of the AuthorizationHandler will be using the
> IS's XACML engine for authorization. It will send a XACML request to the
> PDP and the request will be evaluated against the policies published to the
> PDP. Admins can write XACML policies and publish them to allow/deny the
> users logging into SPs based on those policies.
>
> Also, to retrieve the basic authentication context values (such as SP
> Name, authenticated user's username/userstore/tenant) we will provide a
> default PIP. In case any complex or derived attributes are needed we can
> retrieve them by writing a custom PIP and use them in the policies.
>
> Please share your thoughts and suggestions.
>
> --
> *Pulasthi Mahawithana*
> Senior Software Engineer
> WSO2 Inc., http://wso2.com/
> Mobile: +94-71-5179022
> Blog: http://blog.pulasthi.org
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS] Authorization for Service Providers

[Pulasthi Mahawithana]

Hi All,

As per the current implementation of the Identity Server's authentication
framework, it does not provide any OOTB authorization mechanism for the
service providers. We are going to provide this capability to Identity
server so that the users can be authorized to service providers using rules
based on user attributes, userstore, time of the day, etc.

Following is the proposed sequence for the implementation.


[image: Inline image 1]


The existing authentication flow is kept as is until the authentication
steps are completed and authentication result decided. At the
AuthenticationRequestHandler (after authentication) if the authentication
is success, we will be calling an AuthorizationHandler with the
authentication context. AuthenticationHandler is responsible for evaluating
the configured policies and responding back whether the user is authorized
or not. If the authorization is not required or handled by the SP
itself, we'll be providing the capability of bypassing the authorization
step per service provider .

The default implementation of the AuthorizationHandler will be using the
IS's XACML engine for authorization. It will send a XACML request to the
PDP and the request will be evaluated against the policies published to the
PDP. Admins can write XACML policies and publish them to allow/deny the
users logging into SPs based on those policies.

Also, to retrieve the basic authentication context values (such as SP Name,
authenticated user's username/userstore/tenant) we will provide a default
PIP. In case any complex or derived attributes are needed we can retrieve
them by writing a custom PIP and use them in the policies.

Please share your thoughts and suggestions.

-- 
*Pulasthi Mahawithana*
Senior Software Engineer
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: http://blog.pulasthi.org


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