On Thu, May 25, 2017 at 4:13 PM, Ishara Karunarathna <isha...@wso2.com> wrote:
> HI Ruwan, > > With my understanding ACR is related to the authenticated assurance level. > or we can define specific authentication level. > Ex > acr.level.1 = username pwd athentication > acr.level.2 = step1 : username pwd athentication > step2 : OTP > So if the user send acr as *acr.level.1 *he should be prompt to usrname > pwd authentication and it its level 2 it should be multilevel > authentication. > According to my understanding we should be able to send multiple values for ACR. For an example if client application (service provider) require username pwd athentication + OTP, two values have to be sent in Authorization request for ACR. Also I think ACR value has to play with authenticators but nothing to do with protocol. Correct me if I am wrong. > > And AMR is related to the authentication method, so I think this > implementation will cover AMR requirement where we can pic specific > mechanism > but its hard to handle authentication level. > > So my suggestion is we map different authentication chains to each ACR > values and SP level we associate chains to Sps. > so depend on the acr value we pic relevant authentication chains. > > -Ishara > > > On Thu, May 25, 2017 at 1:04 PM, Ruwan Abeykoon <ruw...@wso2.com> 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.* >> >> > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: > +94717996791 <+94%2071%20799%206791> > > > -- Gayan Gunawardana Senior Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
