Hi,
This PoC illustrates how to achieve this requirement for an application
hosted in tomcat.
And similarly, I believe we can achieve the same for a .NET application
hosted in an IIS using a customerized HTTP module. Please refer the below
examples:

[1] https://msdn.microsoft.com/en-us/library/bb398986.aspx#Features
[2] https://msdn.microsoft.com/en-us/library/xx2w5c88(v=vs.85).aspx


On Fri, Feb 12, 2016 at 4:53 PM, Ruwan Abeykoon <[email protected]> wrote:

> Hi All,
> Any third party applications currently being fronted by AppM will need a
> change in the application side to take the credentials from the JWT and
> associate it with its internal request flow. This is a barrier for
> migrating the existing applications to AppM.
>
> We have a PoC servlet filter or Tomcat Valve option to make it easier to
> migrate an existing J2EE compliant application to AppM. The same technique
> can be used to skipping the login page on non standard Java Web
> Applications, case by case basis.
>
>
> J2EE webapp security is based on request.getPrincipal() and
> request.isUserInRole() standard calls. We have two ways to intercept this
> behaviour and put the Principal and Roles into the request pipeline.
>
> *1. With Servlet Filter*
>
>  We can intercept the request pipeline by adding a servlet filter to the
> web application. In order to do this the web application need to be changed
> 1.1 Adding custom JWTSecurityFilter , by adding jar a file into WEB-INF/lib
> 1.2. Change the "web.xml" adding, and engaging it into the all private
> paths.
>
> <filter>
>     <filter-name>f1</filter-name>
>     
> <filter-class>org.wso2.appm.Security.servlets.JWTSecurityFilter</filter-class>
> </filter>
>
> 1.3. Configuring the custom security xml which matches exactly what
> web.xml <security-constraint> tags do. Because custom filter does not have
> access to web.xml data.
>
> Please see [1] for more information and PoC.
>
>
> *2. Adapter to container request pipeline. E.g. Tomcat Valve*
>
> 2.1 Create a tomcat JWTSecurityValve, similar to TomcatSSOValve
> 2.2. Add the jar to <TomcatHome>/lib
> 2.3 Configure the <TomcatHome/conf/context.xml (or the similar
> configuration on Tomcat based containers, like JBoss)
>
> <Context>
>     <Valve className="org.wso2.tomcat.authenticator.JWTAuthenticatorValve" />
> </Context>
>
> Please see [2] for more information and PoC.
>
>
>
> *Comparing option 1 and 2,*
> *Option 2:* *Valve*,  plugs and affects all the web applications hosted
> on the container. However no change on individual webapp is required. We
> need to write Valve or a Handler for each container and its major versions,
> thus not portable.
> *Option 1:* *Filter*,  plugs only to each webapp individually, and need
> few configuration changes on each webapp. This is appealing when webapp is
> hosted on a container owned by another entity. The filter is a standard
> J2EE construct. It is portable on any J2EE web container.
>
>
>
> [1] https://github.com/visithamanujaya/JWTSecuritySSO/tree/master/Filter
> [2]
> https://github.com/visithamanujaya/JWTSecuritySSO/tree/master/Valve/Tomcat_8
>
> --
>
> *Ruwan Abeykoon*
> *Architect,*
> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
> *lean.enterprise.middleware.*
>
> email: [email protected]
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware

Mobile: +94 715 654154
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to