views:

14

answers:

2

Any user that tries to access some secure resources on my webapp A needs to be authenticated with a webapp B. B has access to the user credentials password etc., I am wondering about the right way to go about this.

One alternative would be to have a filter protecting my secure pages. If a user that is unauthenticated access A secure resource from A, the filter catches the request and redirects the browser to B's login page.

B logs the user in and redirects the browser to the secure page on the A server, along with some B's session id and some token indicatng that the user is logged in.

The filter catches the redirect from B to A, extracts the authentication token info from the header of B's reuest and logs the user in A's session.

All subsequent requests from browser will pass the token that B has set. The filter sees this token and considers the user logged in.

Does this sound sane or am I missing big things ?

Also- is a servletfilter the best way to accomplish this flow ? What about declarative security in web.xml ? How can I accomplish the same flow with using declarative security ?

A: 

For the proposed scheme to work, you need to configure the container to share sessions across web applications. This is not available in all containers unless I'm mistaken, and the configuration steps differ from one container to another. In the absence of session sharing, web application B will simply not recognize the session created by application A. WebLogic Server allows session sharing; others might with varying degress of success.

You might be able to achieve this scheme (after sharing sessions across applications) via declarative security in web app B - the login form of B would have logic to redirect the user to application A where he/she would be authenticated. Needless to say, I haven't tried this out. One thing to watch out for, when using shared sessions, is whether the principals are propagated, or are made available to the second application from the first.

Vineet Reynolds
A: 

Thanks for your reply, Vineet. I may not have been clear, let me rephrase it: A is a webapp that does not have access to username password B is a webapp that does have access to username password The login page lives on B, A simply redirects to it.

They both live in the same domain, but are not able to share sessions etc., for all practical purposes they are completely separate apps.

A wants to use B's access to username/password and create login credentials for a user.

Principals are not propagated directly, but the authenticated users id is sentback.

I understand that logging in with B will create an authenticated session in B and that this session has nothing to do with A. What A is trying to do is this: in lieu of directly accessing user credentials, it is letting B do so and using that yea or nea from B to create an authenticated session. After-all what is an authenticated session - just a session with user information in it right ?

I am wondering also about "identity assertion" and how it may relate to this...

unmaskableinterrupt