As in sequence diagram, we can't do that, and actually do we need that
Associate Tech Lead | WSO2
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 ?
> 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 ?
> On Wed, Oct 19, 2016 at 1:20 AM, Pulasthi Mahawithana <pulast...@wso2.com>
>> 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
>> Architecture mailing list
> *Godwin Amila Shrimal*
> Senior Software Engineer
> WSO2 Inc.; http://wso2.com
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D <http://lnkd.in/KUum6D>*
> twitter: https://twitter.com/godwinamila
> Architecture mailing list
Architecture mailing list