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.

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 <[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.*
>
>


-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to