Hi,

Another requirement I have seen is to have a set of authentication levels
and depending on the required level present a different combinations of
authenticator steps for authentication.
For instance initially a user may be required to authenticated with only
basic the authenticator which will be categorized as basic (or level 1) and
when needs to perform a
privileged action/operation in the application the SP might decide that
current login level is inadequate and will redirect to user to Identity
server to obtain a higher authentication
level (Say level 2 or strongly authenticated), where the user will be
challenged with a set of authenticators from multi-factor steps. the
stepping up of authentication level can be
temporary or permanent for the session.

Eranga.

On Wed, Oct 19, 2016 at 10:18 AM, Godwin Shrimal <god...@wso2.com> wrote:

> As per my previous example, if authorization fails after first step (Basic
> authentication) we should not go for the next step and perform Fido
> authentication. right ?
>
> I am not quiet sure about the scope we are going to cover with this
> implement, Looks there are valid user cases as above.
>
>
> Thanks
> Godwin
>
>
> On Wed, Oct 19, 2016 at 9:56 AM, Harsha Thirimanna <hars...@wso2.com>
> wrote:
>
>> 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/ha
>> rsha-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
>>
>>
>
>
> --
> *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
>
>


-- 
Eranga Perera
*Senior Lead Solutions Engineer*
*WSO2, Inc. *
Mobile :  +94 72 778 4250
eran...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to