[IS] IS 5.5.0 += Adaptive Authentication

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[IS] IS 5.5.0 += Adaptive Authentication

Ruwan Abeykoon
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Ishara Karunarathna
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 <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.




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

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: +94717996791



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Gayan Gunawardana


On Thu, May 25, 2017 at 4:13 PM, Ishara Karunarathna <[hidden email]> 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 <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.




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

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:+94%2071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http://wso2.com/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Prabath Siriwardena
In reply to this post by Ruwan Abeykoon
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 <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
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
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Prabath Siriwardena
In reply to this post by Ishara Karunarathna


On Thu, May 25, 2017 at 3:43 AM, Ishara Karunarathna <[hidden email]> 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.

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.

This is good - but this change has a bigger impact - so we should not worry about taking the authentication chains out of the SP for 5.5.0.

Thanks & regards,
-Prabath
 
so depend on the acr value we pic relevant authentication chains.

-Ishara


On Thu, May 25, 2017 at 1:04 PM, Ruwan Abeykoon <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.




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

email: [hidden email],   blog: isharaaruna.blogspot.com,   mobile: <a href="tel:071%20799%206791" value="+94717996791" target="_blank">+94717996791





--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://facilelogin.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Ruwan Abeykoon
In reply to this post by Prabath Siriwardena

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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:(650)%20625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com



--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [IS] IS 5.5.0 += Adaptive Authentication

Asela Pathberiya


On Wed, May 31, 2017 at 10:38 AM, Ruwan Abeykoon <[hidden email]> wrote:

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.

Yes +1 above changes.   IMO;  If we are going to achieve actual adaptive authentication, we may need to specially consider about the end user.  First end user must be validated & based on the user, we may need to decide the authenticators & also the based on the first steps,  second step must be decided. 

However;  I assume that still we have above interface to extend & decide the given authentication chains in customer manner (without the SP given ACR)

Thanks,
Asela.
 
 

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 <[hidden email]> 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 <[hidden email]> wrote:
Hi All, 
I plan to add the Adaptive authentication on IS. Please provide your feedback on the architecture bellow.

References:


Architecture

 

 

 

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 values

This 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.

 

 

OAuth

external

internal

 

pwd

password

 

otp

smsotp

 

sms

smsotp

 

hwk

fido

 

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

 

 

 

 

 

basic

iwa

fido

oauth-bearer

samlsso

password

Y

 

 

 

Y

smsotp

 

 

 

 

 

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 
lean.enterprise.middleware.




--
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : <a href="tel:(650)%20625-7950" value="+16506257950" target="_blank">+1 650 625 7950

http://facilelogin.com



--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.




--
Thanks & Regards,
Asela

ATL
Mobile : +94 777 625 933
             +358 449 228 979

http://soasecurity.org/
http://xacmlinfo.org/

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Loading...