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 <[email protected]> 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: [email protected] > 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 <[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 >> >> > -- 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
