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: [email protected] 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 <[email protected]> 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 <[email protected]> > 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
