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 <[email protected]> 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 <[email protected]> > wrote: > >> As in sequence diagram, we can't do that, and actually do we need that >> level ? >> >> *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:51 AM, Godwin Shrimal <[email protected]> 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 < >>> [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> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >>> [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 >> >> > > > -- > *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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Eranga Perera *Senior Lead Solutions Engineer* *WSO2, Inc. * Mobile : +94 72 778 4250 [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
