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 <hars...@wso2.com>
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
> <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
>>
>>
>


-- 
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

Reply via email to