Re: [Architecture] [IS] IS 5.5.0 += Adaptive Authentication

[Gayan Gunawardana]

On Thu, May 25, 2017 at 4:13 PM, Ishara Karunarathna 
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  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
>>
>> *    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 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  

Re: [Architecture] Carbon C5 - Server Configuration Model

[Ishara Cooray]

Hi,

What is the conclusion for supporting database configurations in C5
configuration model?
In which kernel version we can expect this ?

For APIM 3.0 we are planning to move database configurations to the new
configuration model.

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Wed, Mar 8, 2017 at 11:55 AM, Imesh Gunaratne  wrote:

> Thanks for the clarification Danesh! In that situation, we might need to
> maintain a default value configuration file per feature or component.
>
> On Wed, Mar 8, 2017 at 10:37 AM, Danesh Kuruppu  wrote:
>
>> Hi Imesh,
>>
>> Shall we use the same default.yaml to define datasources with default
 configuration of the product. because in carbon-datasources, we don't have
 default database configurations and there are coming from different
 components. but we read datasources configuration from carbon-datasources.
 So we need a place to get the default values, if it is not specified in
 deployment.yaml.

>>>
>>> ​According to the initial discussion we had, may be we can have the
>>> default values in the code using annotations. Do we see any problems with
>>> that?
>>>
>>
>> The Problem here is, bean classes related to datasources are defined in
>> carbon-datasources, but the component doesn't contain any default values.
>> It creates databsource objects based on the config files in the datasources
>> directory(in C4, it is based on master-datasources.xml, etc) and
>> configuration files are created or modified at product level.
>>
>> e.g.: If APIM needs separate datasource, it adds related configuration to
>> the datasource config files. So at runtime, carbon-datasources component
>> reads configuration and creates related datasource objects.
>>
>> With the new config model, it is not mandatory to have those
>> configuration in deployment.yaml. So we need to have a place where we can
>> get the default values if it is not specified in the deployment.yaml.
>>
>> Thanks
>> Danesh
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>> Web: WSO2 Inc 
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Danesh Kuruppu]

Hi Ishara,

What is the conclusion for supporting database configurations in C5
> configuration model?
>

We decided to maintain datasource related configuration in deployment.yaml.
There is no default values for datasource configuration. If any product
needs to add datasources, those configurations should mention in the
deployment.yaml.


> In which kernel version we can expect this ?
>

This is in a separate repository(carbon-datasources)[1]. We are going to
add this configuration model in next carbon-datasources release.

1. https://github.com/wso2/carbon-datasources

Thanks
-- 

*Danesh Kuruppu*
Senior Software Engineer | WSO2

Email: dan...@wso2.com
Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
Web: WSO2 Inc 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Carbon C5 - Server Configuration Model

[Ishara Cooray]

Thanks Danesh.

Do we have a time line for next carbon-datasources release?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Mon, May 29, 2017 at 7:11 PM, Danesh Kuruppu  wrote:

> Hi Ishara,
>
> What is the conclusion for supporting database configurations in C5
>> configuration model?
>>
>
> We decided to maintain datasource related configuration in
> deployment.yaml. There is no default values for datasource configuration.
> If any product needs to add datasources, those configurations should
> mention in the deployment.yaml.
>
>
>> In which kernel version we can expect this ?
>>
>
> This is in a separate repository(carbon-datasources)[1]. We are going to
> add this configuration model in next carbon-datasources release.
>
> 1. https://github.com/wso2/carbon-datasources
>
> Thanks
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
> Web: WSO2 Inc 
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture