[UUF] Pluggable Authentication mechanism for UUF

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[UUF] Pluggable Authentication mechanism for UUF

Sagara Gunathunga-2

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com


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

Re: [UUF] Pluggable Authentication mechanism for UUF

Manuranga Perera
One problem I see with this is:
How does the filter know to create a session or not? Because not every page needs a session. Eg: in J2EE you have getSession [1], only the Servlet that call it, it will return a session. Similarly UUF has a {{seucre}} tag that marks which pages are secure. It's better if this plug-able security work with that.

[1] https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequest.html#getSession()


On Sat, Jan 21, 2017 at 4:11 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com


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




--
With regards,
Manuranga Perera.

phone : 071 7 70 20 50
mail : [hidden email]

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

Re: [UUF] Pluggable Authentication mechanism for UUF

Johann Nallathamby
In reply to this post by Sagara Gunathunga-2
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950

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

Re: [UUF] Pluggable Authentication mechanism for UUF

Chandana Napagoda
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : +94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  chandana@wso2.com | cnapagoda@gmail.com
Mobile : +94718169299
Blog  :    http://blog.napagoda.com | http://chandana.napagoda.com
Linkedin : http://www.linkedin.com/in/chandananapagoda
Reply | Threaded
Open this post in threaded view
|

Re: [UUF] Pluggable Authentication mechanism for UUF

Nuwan Dias
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

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

Re: [UUF] Pluggable Authentication mechanism for UUF

Vidura Nanayakkara
Hi All,

We are currently in the process of implementing extensible authentication for Carbon UUF. Our approach would be as described below:

Adding an authentication extension point
  • The web developer will be provided with an interface to implement the authentication logic. For instance, this could be an SSO authentication or a token based authentication.

Figure 1: Authenticator interface
  • The web developer will need to specify the `Authenticator` implementation class name and the authentication URIs in the `app.yaml` configuration.
​Example: ​
...​
authentication:
    authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
    uris:
        - "/login"
        - "/logout"
        - "/acs"
​...​

How UUF framework do the authentication

UUF will check whether the current request matches one of the configured authentication URI patterns before rendering a page. If the request matches any of the authentication URIs then the UUF framework will execute the authentication logic implemented. For instance, in an SSO scenario, a developer will be redirected to the IDP URL or in a form param based login scenario a developer will be forward to the login page when the login fails.


​​Figure 2: How UUF framework authenticates


WDYT?

Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : +94 (0) 717 919277

On Tue, Mar 28, 2017 at 9:02 AM, Nuwan Dias <[hidden email]> wrote:
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : +94 (0) 717 919277

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

Re: [UUF] Pluggable Authentication mechanism for UUF

Asela Pathberiya


On Wed, May 24, 2017 at 3:24 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi All,

We are currently in the process of implementing extensible authentication for Carbon UUF. Our approach would be as described below:

Adding an authentication extension point
  • The web developer will be provided with an interface to implement the authentication logic. For instance, this could be an SSO authentication or a token based authentication.

Figure 1: Authenticator interface
  • The web developer will need to specify the `Authenticator` implementation class name and the authentication URIs in the `app.yaml` configuration.

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

Can't we use the existing way which figures out the authenticator dynamically based on the request....   In older authenitcator,  it is used a canHandle() method [1]. Basically you may have a single logout & login endpoints & authenticator is identify based on the request..


Thanks,
Asela.
 
​Example: ​
...​
authentication:
    authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
    uris:
        - "/login"
        - "/logout"
        - "/acs"
​...​

How UUF framework do the authentication

UUF will check whether the current request matches one of the configured authentication URI patterns before rendering a page. If the request matches any of the authentication URIs then the UUF framework will execute the authentication logic implemented. For instance, in an SSO scenario, a developer will be redirected to the IDP URL or in a form param based login scenario a developer will be forward to the login page when the login fails.


​​Figure 2: How UUF framework authenticates


WDYT?

Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

On Tue, Mar 28, 2017 at 9:02 AM, Nuwan Dias <[hidden email]> wrote:
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
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
Reply | Threaded
Open this post in threaded view
|

Re: [UUF] Pluggable Authentication mechanism for UUF

Vidura Nanayakkara
Hi Asela,

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

With the above approach, you can use any type of authenticator in the UUF app (for instance SSO authenticator or a form post authenticator). Having two methods to `login()` and `logout()` will be more convenient as you have mentioned. However, if you consider an SSO authentication scenario, when you have the ACS URL, we will not know whether to call the `login()` method or the `logout()` method. Because of this reason we have decided you use a single `authenticate()` method to handle both login and logout scenarios. 

Best Regards,
Vidura Nanayakkara

On Wed, May 24, 2017 at 3:51 PM, Asela Pathberiya <[hidden email]> wrote:


On Wed, May 24, 2017 at 3:24 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi All,

We are currently in the process of implementing extensible authentication for Carbon UUF. Our approach would be as described below:

Adding an authentication extension point
  • The web developer will be provided with an interface to implement the authentication logic. For instance, this could be an SSO authentication or a token based authentication.

Figure 1: Authenticator interface
  • The web developer will need to specify the `Authenticator` implementation class name and the authentication URIs in the `app.yaml` configuration.

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

Can't we use the existing way which figures out the authenticator dynamically based on the request....   In older authenitcator,  it is used a canHandle() method [1]. Basically you may have a single logout & login endpoints & authenticator is identify based on the request..


Thanks,
Asela.
 
​Example: ​
...​
authentication:
    authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
    uris:
        - "/login"
        - "/logout"
        - "/acs"
​...​

How UUF framework do the authentication

UUF will check whether the current request matches one of the configured authentication URI patterns before rendering a page. If the request matches any of the authentication URIs then the UUF framework will execute the authentication logic implemented. For instance, in an SSO scenario, a developer will be redirected to the IDP URL or in a form param based login scenario a developer will be forward to the login page when the login fails.


​​Figure 2: How UUF framework authenticates


WDYT?

Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

On Tue, Mar 28, 2017 at 9:02 AM, Nuwan Dias <[hidden email]> wrote:
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+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




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : +94 (0) 717 919277

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

Re: [UUF] Pluggable Authentication mechanism for UUF

Asela Pathberiya


On Wed, May 24, 2017 at 5:38 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Asela,

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

With the above approach, you can use any type of authenticator in the UUF app (for instance SSO authenticator or a form post authenticator). Having two methods to `login()` and `logout()` will be more convenient as you have mentioned. However, if you consider an SSO authentication scenario, when you have the ACS URL, we will not know whether to call the `login()` method or the `logout()` method. Because of this reason we have decided you use a single `authenticate()` method to handle both login and logout scenarios. 

In SSO;  you can define two acs url for login/logout..   Also;  if it is logout request, logout method can be called.. 

According to the above;  For each authenticator;  do we need to define different contexts ?  It does not seem to be correct..
 

Best Regards,
Vidura Nanayakkara

On Wed, May 24, 2017 at 3:51 PM, Asela Pathberiya <[hidden email]> wrote:


On Wed, May 24, 2017 at 3:24 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi All,

We are currently in the process of implementing extensible authentication for Carbon UUF. Our approach would be as described below:

Adding an authentication extension point
  • The web developer will be provided with an interface to implement the authentication logic. For instance, this could be an SSO authentication or a token based authentication.

Figure 1: Authenticator interface
  • The web developer will need to specify the `Authenticator` implementation class name and the authentication URIs in the `app.yaml` configuration.

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

Can't we use the existing way which figures out the authenticator dynamically based on the request....   In older authenitcator,  it is used a canHandle() method [1]. Basically you may have a single logout & login endpoints & authenticator is identify based on the request..


Thanks,
Asela.
 
​Example: ​
...​
authentication:
    authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
    uris:
        - "/login"
        - "/logout"
        - "/acs"
​...​

How UUF framework do the authentication

UUF will check whether the current request matches one of the configured authentication URI patterns before rendering a page. If the request matches any of the authentication URIs then the UUF framework will execute the authentication logic implemented. For instance, in an SSO scenario, a developer will be redirected to the IDP URL or in a form param based login scenario a developer will be forward to the login page when the login fails.


​​Figure 2: How UUF framework authenticates


WDYT?

Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

On Tue, Mar 28, 2017 at 9:02 AM, Nuwan Dias <[hidden email]> wrote:
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+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




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
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
Reply | Threaded
Open this post in threaded view
|

Re: [UUF] Pluggable Authentication mechanism for UUF

Vidura Nanayakkara
​Hi Asela,

On Wed, May 24, 2017 at 6:39 PM, Asela Pathberiya <[hidden email]> wrote:


On Wed, May 24, 2017 at 5:38 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi Asela,

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

With the above approach, you can use any type of authenticator in the UUF app (for instance SSO authenticator or a form post authenticator). Having two methods to `login()` and `logout()` will be more convenient as you have mentioned. However, if you consider an SSO authentication scenario, when you have the ACS URL, we will not know whether to call the `login()` method or the `logout()` method. Because of this reason we have decided you use a single `authenticate()` method to handle both login and logout scenarios. 

In SSO;  you can define two acs url for login/logout..   Also;  if it is logout request, logout method can be called.. 
+1. Myself, SajithAR and Tanya​ had an offline discussion aswell regarding this. We planned on taking advantage of URI patterns. For login URIs the pattern would be "/login/*" and for logout URIs the pattern would be "/logout/*". For instance, in SSO, the login URI would be /login/acs and the logout URI would be /logout/acs. If the request matches the login URI pattern, we can invoke `Authenticator.login()` method and if the request matches the logout URI pattern we can invoke the `Authenticator.logout()` method.

According to the above the `Authenticator` interface would be changed as shown below:



​Furthermore as per the above, the web developer only needs to specify the `Authenticator` implementation in the `app.yaml` configuration.

Example:
​...​
authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
​...​

According to the above;  For each authenticator;  do we need to define different contexts ?  It does not seem to be correct..

​For an UUF app, you can only have one `Authenticator`​. The webapp developer needs to configure the desired Authenticator for their webapp.


​Best Regards,
Vidura Nanayakkara​
 
 

Best Regards,
Vidura Nanayakkara

On Wed, May 24, 2017 at 3:51 PM, Asela Pathberiya <[hidden email]> wrote:


On Wed, May 24, 2017 at 3:24 PM, Vidura Nanayakkara <[hidden email]> wrote:
Hi All,

We are currently in the process of implementing extensible authentication for Carbon UUF. Our approach would be as described below:

Adding an authentication extension point
  • The web developer will be provided with an interface to implement the authentication logic. For instance, this could be an SSO authentication or a token based authentication.

Figure 1: Authenticator interface
  • The web developer will need to specify the `Authenticator` implementation class name and the authentication URIs in the `app.yaml` configuration.

Does it contain only authenticate() method ?..  It means that then /logout request is hit, it would be called the same authenticate() method which may be confusing...  

Can't we use the existing way which figures out the authenticator dynamically based on the request....   In older authenitcator,  it is used a canHandle() method [1]. Basically you may have a single logout & login endpoints & authenticator is identify based on the request..


Thanks,
Asela.
 
​Example: ​
...​
authentication:
    authenticator: "org.wso2.carbon.uuf.sample.SsoAuthenticator"
    uris:
        - "/login"
        - "/logout"
        - "/acs"
​...​

How UUF framework do the authentication

UUF will check whether the current request matches one of the configured authentication URI patterns before rendering a page. If the request matches any of the authentication URIs then the UUF framework will execute the authentication logic implemented. For instance, in an SSO scenario, a developer will be redirected to the IDP URL or in a form param based login scenario a developer will be forward to the login page when the login fails.


​​Figure 2: How UUF framework authenticates


WDYT?

Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

On Tue, Mar 28, 2017 at 9:02 AM, Nuwan Dias <[hidden email]> wrote:
The Publisher/Store/Admin apps on API Manager 3.0.0 is built using an SPA architecture. The apps are OAuth clients which obtain an access token to call the respective APIs. However these Apps will still have a server side component which performs standard-auth or single sign on to log a user in and get an access token using a suitable mechanism.

The authorization aspects are handled using OAuth2.0 scopes.

On Mon, Mar 27, 2017 at 9:55 PM, Chandana Napagoda <[hidden email]> wrote:
Hi Johan,

We are expecting to introduce a plugable authorization extension point for UUF framework. Initially, we thought to use MSF4j interceptors to achieve this,  but if we use interceptors, those would get hit for all the requests served by the application. Further interceptors will be invoked before requests reaching to the UUF framework. Hence we will not be able to access the app configurations and related information within the interceptor. So that interceptor will not be able to differentiate login and logout requests from the other requests, and we need to process application configurations from two locations.

As per the offline discussion had with Azzez, Sagara, RuwanA and SajithAr, we decided not to use msf4j interceptors and expecting to introduce an interface which is handling login and logout requests. Based on the use case, app or component developer should implement this interface and need to deploy it as an OSGi bundle.

So login URL, logout URL and authentication implementation should be configured via the app.yaml file. So UUF framework will forward the requests to the relevant implementation. 

However, since APIM is implemented using SPA approach(client side), their authentication mechanism might differ from the UUF. 

Regards,
Chandana

On Mon, Mar 27, 2017 at 8:59 PM, Johann Nallathamby <[hidden email]> wrote:
I have a slightly different opinion on the architecture. Personally I would like to keep this architecture as simple as possible at the same time supporting all the plugin requirements. What I suggest is the following.

Just have one MSF4J interceptor layer which is responsible for processing any authenticated token such as SAML2, JWT, cookie, etc. This will be our main extension point. This layer will not validate session. It will just check for known tokens and if found it will process them, create a bean object, and set a request attribute that will be passed on to the UUF framework. If a known token is not found also still the request will go through to UUF without the request attribute.

Improve UUF, to support anonymous or protected resources. I think this is what Manu is referring to. By looking at whether the page has a secure flag or not UUF can decide if the page can be rendered or not. If the page is not secure it will anyway be rendered. If the page is secure, UUF will look for the authentication bean request attribute set by the interceptor layer and only if found allow to access the resource. If not throw an error.

The view and the controller part of this interaction will be completely handled as a UUF UI component which doesn't have any dependency with the backend or interceptor. The UUF UI component is solely responsible to handle the UI experience of the user, to be redirected to an IDP, and bring back a token. Once the token is received the UUF component will make an http call with the token. This is when the backend components will get involved in processing the token. These UUF components can be written as reusable components across products to reduce code duplication.

Why I feel this might be a better option is,

1. The Carbon UI Authentication Framework in C4 was a failure IMO. It wasn't extensible as much as we thought it would be. It was very tightly coupled to the UI and SOAP. Still you can find SAML2 SSO related code in the org.wso2.carbon.ui JSP pages. Therefore I would like to as much as possible decouple any view/controller logic from backend, and leave it to the UI components.

2. Backend authenticator (interceptor) Java developers don't need to worry about UUF. Leave the UX/redirections, etc. to be handled by UUF developers who are competent with FE/BE JS.

3. No need to introduce any new API to obtain http session information. The sessions are completely managed by UUF.

4. In the above design suggested by Sagara there are 3 interceptors with a dependency on the order. I don't know if the interceptor ordering has been implemented yet.

5. We have already implemented Rest API protection using MSF4J interceptors for IS 6.0.0 M3. Ideally this must be reusable since we are talking about the same thing here.

@Chandana/SajithAR/NuwanD/SajithK:
I know you guys have started implementing this for API Store/Publisher for C5. Can you guys please explain how you are planning to do this? Is it similar to one of the above approaches or somewhat different? Ideally IS 6.0.0 User/Admin Portals must be able to reuse your component. If needed let's have a meeting to figure out how we are going to reuse your stuff.

Regards,
Johann.


On Sat, Jan 21, 2017 at 9:41 PM, Sagara Gunathunga <[hidden email]> wrote:

For IS portals we have a requirement to plug authentication mechanisms, at least we have to support BasicAuth and SAML SSO OOTB. We had a meeting with UUF folks about this requirements and identified the lack of such support in current UUF implementation, we mainly discussed whether we should implement an UUF specific feature once a request reach to UUF level or whether we should perform AuthN at MSF4J level before reach to UUF level. 

After evaluating both options we concluded to reuse MSF4J's existing security Interceptor mechanism for UUF as well, as it much clean, consistent and pluggable. Additionally this approach work for both UUF pages and UI specific APIs too. Following 2 diagrams illustrate 2 example scenarios based on BasicAuth and SAML SSO. 


      
Inline image 1



Inline image 2

- in above examples, requests first hit SessionValidationInterceptor. SessionValidationInterceptor check whether a HTTP session exists or not, if exists set a flag to bypass other AuthN Interceptor/s in the chain. 

- BasicAuthInterceptor/SAMLSSOInterceptor  are AuthN protocol  specific and perform the AuthN based in underline protocol.  

-  AuthenticationValidationInterceptor, this will hit as the last Interceptor in the chain and won't allow any request to pass this point without AuthN details. 


Improvements required form MSF4J

- Ability to configure Interceptors in global/service level and ability to specify order of the Interceptors. This feature is already being developed by Vidura based on API-M product API requirements hence no additional effort here. 

- Unlike MSF4J Interceptors used in service, here we have to created HTTP Session after successful AuthN. We  have to design an API and implement this feature. 

- Check how MSF4J behave with browser- based HTTP features such as redirects.   


Improvements required form UUF

- Session created by MSF4J level should be visible to UUF level so that UUF components can read/write values from/to session.     
- We haven't discuss about AuthZ  yet. 
    

[1] - [Design Review] [IAM]User Portal :by - [hidden email] 
[2] - [Architecture][MSF4J] MSF4J Filter Configuration 



Thanks ! 
-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com




--
Thanks & Regards,

Johann Dilantha Nallathamby
Technical Lead & Product Lead of WSO2 Identity Server
Governance Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94777776950



--
Chandana Napagoda
Associate Technical Lead
WSO2 Inc. - http://wso2.org
Email  :  [hidden email]
Mobile : <a href="tel:+94%2071%20816%209299" value="+94718169299" target="_blank">+94718169299
Blog  :    http://cnapagoda.blogspot.com | http://chandana.napagoda.com




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+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




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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




--
Thanks & Regards,
Asela

ATL
Mobile : <a href="tel:+94%2077%20762%205933" value="+94777625933" target="_blank">+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




--
Best Regards,

Vidura Nanayakkara
Software Engineer

Mobile : <a href="tel:+94%2071%20791%209277" value="+94717919277" target="_blank">+94 (0) 717 919277

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