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
<http://wso2.com/signature>

On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana <prab...@wso2.com>
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
>>
>> <https://wso2.com/signature>
>>
>
>
>
> --
> 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

Reply via email to