Hi Prabath,
> Please check whether my understanding is correct based on the following > mail.. > > 1. We define set of ACR values at the framework level - which are agnostic > to the inbound protocols. > 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values - > but must be mapped to the ACR values defined at the framework level. > 3. Each ACR value will represent a set of authenticators (or steps) - I > guess your Table-2 is representing that. > Yes. > 1. If you take OIDC as an example, you can send multiple acr_values in the > request (space separated - and by preference). I would suggest the protocol > specific component will pick one out of that - and will pass the mapped ACR > value to the framework - and the same will be included in the response as > the value of the acr parameter. > 2. Once the user is authenticated, the framework will return back the > authenticators used in each step. Once again the protocol specific > component has to match these to corresponding AMR values and send back to > the service provider. > > Few suggestions.. > > 1. IMO we should let each service provider define multiple authentication > chains - and one would be the default one (so this will not break the > current behavior). > 2. Each chain can be associated with one or more ACR values. > 3. Right now the authentication chain corresponding to a service provider > is loaded by its name. But with this design it will be by the name and the > ACR value. > I will change the architecture with above suggestions. > > This will require minimal changes at the framework level. > > Also - let's keep adaptive authentication out of this. We can address that > separately - and I don't think we need to have it for IS 5.5.0. > > Noted. I will create new mail thread specific to ACR and AMR and continue discussion with updated architecture. Cheers, Ruwan On Wed, May 31, 2017 at 3:59 AM, Prabath Siriwardena <[email protected]> wrote: > Hi Ruwan, > > Please check whether my understanding is correct based on the following > mail.. > > 1. We define set of ACR values at the framework level - which are agnostic > to the inbound protocols. > 2. Each inbound protocol (OIDC, SAML) - can define their own ACR values - > but must be mapped to the ACR values defined at the framework level. > 3. Each ACR value will represent a set of authenticators (or steps) - I > guess your Table-2 is representing that. > Few other things I assume we should be doing (not clearly mentioned in the > mail).. > > > 1. If you take OIDC as an example, you can send multiple acr_values in the > request (space separated - and by preference). I would suggest the protocol > specific component will pick one out of that - and will pass the mapped ACR > value to the framework - and the same will be included in the response as > the value of the acr parameter. > 2. Once the user is authenticated, the framework will return back the > authenticators used in each step. Once again the protocol specific > component has to match these to corresponding AMR values and send back to > the service provider. > > Few suggestions.. > > 1. IMO we should let each service provider define multiple authentication > chains - and one would be the default one (so this will not break the > current behavior). > 2. Each chain can be associated with one or more ACR values. > 3. Right now the authentication chain corresponding to a service provider > is loaded by its name. But with this design it will be by the name and the > ACR value. > > This will require minimal changes at the framework level. > > Also - let's keep adaptive authentication out of this. We can address that > separately - and I don't think we need to have it for IS 5.5.0. > > Thanks & regards, > -Prabath > > > On Thu, May 25, 2017 at 12:34 AM, Ruwan Abeykoon <[email protected]> wrote: > >> Hi All, >> I plan to add the Adaptive authentication on IS. Please provide your >> feedback on the architecture bellow. >> >> References: >> http://openid.net/specs/openid-connect-core-1_0.html#Authori >> zationEndpoint >> https://tools.ietf.org/html/draft-ietf-oauth-amr-values-02 >> >> >> Architecture >> >> * <https://www.draw.io/#G0B0bx735ZWbanTEZRQW8zcGFsanc> Figure 1: >> Framework and Endpoints Authentication Context Class Reference(ACR)* >> >> >> >> >> >> >> >> >> *Different protocols may support different values for ACR. Hence We >> provide two levels of mapping from protocol based ACR to internal >> authenticators. 1. Protocol ACR values to Internal ACR valuesThis is a map >> between external(protocol or customer specific) ACR values to internal >> representation. This is a key-value pair. Both the key and value are >> arbitrary Strings. 1. Internal ACR values vs supported Authenticators >> table. This is a table specifying which “internal ACR” are supported by >> each “Authenticator”.The Authenticator may be internal authenticator or a >> federated authenticator. This may be a custom built authenticator or may be >> installed as a connector. These two information will be added to >> “identity.xml”, as XML Info-set. These configurations are per server, and >> can not be changed per tenant >> basis. OAuthexternalinternal pwdpassword otpsmsotp smssmsotp hwkfido Table >> 1: ACR mapping based on protocol Note that the “external” value in the >> above table may be a URI.E.g. >> urn:oasis:names:tc:SAML:2.0:ac:classes:Password >> urn:oasis:names:tc:SAML:2.0:ac:classes:X509 >> urn:federation:authentication:windows >> urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos >> Autnenticator basiciwafidooauth-bearersamlssopasswordY Ysmsotp >> fido Y Table >> 2: ACR mapping internal-ACR to Authenticator *Implementation >> >> It is the responsibility of the relevant endpoint to decide if ACR is >> requested at the protocol level and add them into AuthenticatonContext. >> AutnenticationContext will be enhanced by adding new methods. >> >> >> >> public void setAcr(List<String> acrRequested); >> >> public void setAcrRule(AcrRule acrRule) >> >> >> >> enum AcrRule { >> >> EXACT, >> >> MINIMUM, >> >> MAXIMUM, >> >> BETTER >> >> } >> >> >> As of IS 5.3.0, Authentication Sequence is built via >> FileBasedConfigurationBuilder >> And UIBasedConfigurationBuilder. A new AdaptiveConfigurationBuilder will >> be added to wrap the calls to both of the previous builders. The Adaptive >> builder will examine the Authentication Context to see if there are any ACR >> requested. If requested, the original sequence will be modified according >> to requested ACR list. >> >> >> >> The “AdaptiveConfigurationBuilder” will use an extension mechanism, which >> can be supplied by OSGI bundle if needed, for any change of the default >> behaviour. For example this evaluator can be extended with analytics to >> decide if the current login attempt is suspicious and to select next level >> of security. >> >> >> public interface AdaptiveAuthenticationEvaluator { >> >> >> >> /** >> >> * Evaluates if this step is applicable on the current authentication >> context. >> >> .. >> >> */ >> >> boolean isApplicable(StepConfig stepConfig, AuthenticationContext >> context); >> >> } >> >> >> >> The other aspects of framework remains architecturally unchanged as the >> framework relies on the bre-bult Sequence to perform authentication >> completion. >> >> >> >> >> >> Cheers, >> >> Ruwan >> >> >> -- >> >> *Ruwan Abeykoon* >> *Associate Director/Architect**,* >> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >> *lean.enterprise.middleware.* >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 <(650)%20625-7950> > > http://facilelogin.com > -- *Ruwan Abeykoon* *Associate Director/Architect**,* *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * *lean.enterprise.middleware.*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
