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#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.* > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
