As in sequence diagram, we can't do that, and actually do we need that level ?
*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:51 AM, Godwin Shrimal <god...@wso2.com> wrote: > How can we attach authorization handlers in steps level with the current > design ? > > Ex. > Step1 : Do basic authentication > Step2 : Perform authorization for above authenticated user > Step3 : Perform Fido authentication > > In that case don’t we need to handle it in Step level ? same as how we > handle Authenticators ? > > > > Thanks > Godwin > > On Wed, Oct 19, 2016 at 1:20 AM, 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> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Godwin Amila Shrimal* > Senior Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: *+94772264165* > linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>* > twitter: https://twitter.com/godwinamila > <http://wso2.com/signature> > > _______________________________________________ > 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