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#AuthorizationEndpoint 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.*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
