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
Thanks & regards,
On Wed, Oct 19, 2016 at 12:01 AM, Harsha Thirimanna <hars...@wso2.com>
> 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
> On Wed, Oct 19, 2016 at 9:26 AM, Prabath Siriwardana <prab...@wso2.com>
>> Do we execute the authorization handler for each request...? even the
>> user is authenticated...?
>> Thanks & regards,
>> 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,
>> Twitter : @prabath
>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>> Mobile : +1 650 625 7950
>> Architecture mailing list
Thanks & Regards,
Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
Mobile : +1 650 625 7950
Architecture mailing list