SS0 and GWT

[mwk]

Hi All-

I'm a new user who has been tasked with refactoring a GWT 2.3
application so that it can work behind something like Schibboleth or
OpenAM, as well as maintain a it's own authentication page/panel.

Searching the forum, I notice that most people when talking about
authentication are suggesting that systems authenticate via some RPC
service. This works fine so long as you're not behind a SSO Gateway/
proxy that sticks a user key on as a http header, works fine.

Given a requirement that it work in this type of environment, is there
a best-practice, GWT-thumbs up way to do this?

Are servlet filters still a suggested way to do this? Can I integrate
a redirecting servlet filter so that it'll behave with regard to RPC
calls(redirecting the whole browser when the RPC call is redirected to
the SSO Auth page)?

Any suggestions would be approved

thanks
Mike

[Thomas Broyer]

My first app used in-app authentication (because the client wanted to bake a "lock screen after 30 minutes of inactivity" in the webapp rather than relying on the OS's built-in mechanism) and it caused us all sorts of issues (disclaimer: at that time, Ray Ryan didn't praise MVP, decoupling via an event bus and those sorts of things, so that was mostly an app architecture issue: clearing caches each time the user logged out so that you don't leak data if you sign in as a different user, and you always forget one cache; we ended up refreshing the page on logout, at the expense of throwing out caches of non-sensitive data –and we loaded them using RESTful requests to benefit from HTTP caching–).

I'm now a big fan of decoupling authentication from the app. That way you can change the authentication mechanism without impact the app. Our current app relies on the servlet container for the authentication and roles (using <security-constraint>s in the web.xml). We include a <login-config><auth-method>FORM</auth-method>...</login-config> in the web.xml as a default, that we can override (at the servlet-container level and/or using a web-override.xml) when we need to use an SSO (such as Jasig CAS) or another mean to authenticate users (HTTP Digest, HTTPS with client-certificates). And we use JAAS to actually do the authentication, shipping a default configuration using text files (and a template for connecting to an LDAP server).

That way, it's really easy to support deploying the same app in different environments:

• form-based login with user credentials and roles in text files (default configuration)
• form-based login delegating to an LDAP for authentication
• SSO

Using JAAS chaining capabilities, we can even authenticate with LDAP or Jasig CAS, and provide roles from a text file.

That way, the app becomes easier to code too, as we know the user is authenticated when the page loads, and it won't change for the whole lifetime of the GWT app.

We use a dynamic host page to provide the user name to the GWT app. We do NOT require auth (at the web.xml level) on our AJAX endpoints (RequestFactoryServlet, file-upload servlets; it would be the same for GWT-RPC) and instead handle it in a servlet filter: if there's no authenticated user, return a 4xx status code; and on the client-side, handle those cases –user has been logged out by some external mean, not from the GWT app; e.g. session has expired– by asking the user to refresh the page (don't refresh automatically, so they can do some copy/paste to "backup" their unsaved changes).

BTW, it seems like it's exactly how Google does authentication on their apps.

[Ed]

An alternative to using a Authentication filter would be to use a
Dynamic Proxy that form a central point of access to your public
methods (I use this between all my backend layers).

The proxy captures all RPC requests and controls authentication and
authorisation.
I do send a caller id with every RPC call that is contained in cookie
filled by the backend and can only read by the front-end app.
The proxy will stripe of the caller id before forwarding the call and
will check the correctness of the id. It "overcomes" XSS attacks.
I use annotations on the public methods to defines the authentication/
authorization levels and inject the logged in user as an extra
argument if indicated in the annotation (completely decoupled
methods).
Injection of the user is required in a multi threading environment as
when you allow access to a method, in the mean time the session might
expire and access to a method is incorrectly granted and causes
exceptions when the method retrieves the loggedin user.
If a loggedin user is required but not present, an login exception
will be thrown and picked up by the central front end Service handler
that will make a forward to any login url. This will be responsible of
performing authentication, inform the backend and return to any url.

Hope this give you some idea's.
- Ed

[Alberto]

Thomas,

Could you explain what do you check at the filter level? How do you
know if a user is authenticated when you make a GWT-RPC call? It is a
newbie question, I know, but it is not clear to me if we are
identifying the user by a query parameter or a HTTP header.

Thanks

On Dec 7, 4:01 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> My first app used in-app authentication (because the client wanted to bake
> a "lock screen after 30 minutes of inactivity" in the webapp rather than
> relying on the OS's built-in mechanism) and it caused us all sorts of
> issues (disclaimer: at that time, Ray Ryan didn't praise MVP, decoupling
> via an event bus and those sorts of things, so that was mostly an app
> architecture issue: clearing caches each time the user logged out so that
> you don't leak data if you sign in as a different user, and you always
> forget one cache; we ended up refreshing the page on logout, at the expense

> of throwing out caches of non-sensitive data –and we loaded them using *
> RESTful* requests to benefit from HTTP caching–).

>
> I'm now a big fan of decoupling authentication from the app. That way you
> can change the authentication mechanism without impact the app. Our current
> app relies on the servlet container for the authentication and roles (using
> <security-constraint>s in the web.xml). We include a
> <login-config><auth-method>FORM</auth-method>...</login-config> in the
> web.xml as a default, that we can override (at the servlet-container level
> and/or using a web-override.xml) when we need to use an SSO (such as Jasig
> CAS) or another mean to authenticate users (HTTP Digest, HTTPS with
> client-certificates). And we use JAAS to actually do the authentication,
> shipping a default configuration using text files (and a template for
> connecting to an LDAP server).
> That way, it's really easy to support deploying the same app in different
> environments:
>

>    - form-based login with user credentials and roles in text files
>    (default configuration)
>    - form-based login delegating to an LDAP for authentication
>    - SSO

>
> Using JAAS chaining capabilities, we can even authenticate with LDAP or
> Jasig CAS, and provide roles from a text file.
>
> That way, the app becomes easier to code too, as we know the user is
> authenticated when the page loads, and it won't change for the whole
> lifetime of the GWT app.
>

> We use a dynamic host page<http://code.google.com/webtoolkit/articles/dynamic_host_page.html>to provide the user name to the GWT app. We do NOT require auth (at the

[Ed Bras]

You could check it like this:

Normally my RPC calls look something like this:

modifyDeclarationOfLoggedInMember(DeclarationDto member);

Notice that you don't send the logged in member along as it's known in the backend.

The logged in member is present in the session (at least his id).

If the is is present, it's a valid request -> authentication: this can be done in a servlet filter.

Besides that you have to do some sort of authorization if required (is the allowed to modify the declaration in the call above).

- Ed

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Wednesday, December 7, 2011 5:03:05 PM UTC+1, Alberto wrote:

Thomas,

  Could you explain what do you check at the filter level? How do you
know if a user is authenticated when you make a GWT-RPC call? It is a
newbie question, I know, but it is not clear to me if we are
identifying the user by a query parameter or a HTTP header.

We totally delegate authentication to the servlet container (or a servlet filter if that's really needed), so my AjaxAuthenticationFilter is as easy as:

  public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain)

      throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) servletRequest;

    HttpServletResponse response = (HttpServletResponse) servletResponse;

    if (request.getUserPrincipal() == null) {

      // XXX: HTTP/1.1 requires a WWW-Authenticate header for 401 responses, but in practice it's not needed.

      response.sendError(HttpServletResponse.SC_UNAUTHORIZED);

      return;

    }

    filterChain.doFilter(servletRequest, servletResponse);

  }

And on the client-side, we check for com.google.gwt.http.client.Response#getStatusCode() == Response.SC_UNAUTHORIZED.

 

Thanks

[Alberto]

Thanks a lot! This gives me a very good head start.