Filter Question

[lightguard]

I'm looking at doing an SSO type thing for a project that will get the token from another program that further up the stream.  Basically it'll include the token as an HTTP Header (from what I understand this is pretty common).  I've seen posts about doing SSO with filters.  Makes perfect sense and I'm pretty sure that's the route I will take.  My question is where to put the filter in the stream.  Is it within the AuthenicationFilter or around it or somewhere else?  What makes the most sense?

[lightguard]

Or does the Windows SSO make more sense?

[lightguard]

Jason Porter wrote on Jun 20, 2008 00:38:


Or does the Windows SSO make more sense?

the approach

[gjeudy]

It depends what SSO technology you will be using. Windows SSO works if want to use the windows login as the central authentication system. There are other SSO solutions around like SiteMinder, JOSSO, etc.. I would guess that implementing Windows SSO is easiest as this is normally what you get for free in a typical enterprise environment (no need to install special software or buy SSO software licenses).

The approach to implement the SSO solution will vary depending of what SSO technology you have choosen but this often comes down to populate a token in the HTTP header to authenticate the request. Then on the server side you will just need to read the token and authentify against a Windows domain controller for example or something else if you are not using Windows SSO. You should look for libraries that do this for you.

If you don't know where to go and don't have more info on your SSO requirements I would suggest you go the Windows SSO route and use JCIFS library to handle the work of authentifying the NTLM token to the domain controller.

[lightguard]

Understandable.   I'm not in the loop on the decision for the SSO solution, just trying to implement the proof-of-concept.  I've been told all of the options we're looking at will populate an HTTP header.  I'm simply wondering if a seam filter (@Filter) is a good way to go, and if so if it should around or in the AuthenticationFilter or elsewhere.

[gjeudy]

The AuthenticationFilter is not installed by default:

@Install(value = false, precedence = BUILT_IN)

moreover if you look at the code it only prepopulates credentials in a BASIC or DIGEST authentication, therefore it is pretty useless with respect to an SSO solution.

I think you can pretty confidently show them a proof-of-concept, using a servlet filter is the correct approach. Whether you code your servlet filter or use a 3rd party filter to populate your Principal object in the HTTP session is up to you.

It doesn't have to be part of the Seam filter stack as all other filters have nothing to do with security.

All Seam SSO solutions I've seen so far was to later retrieve the Principal object from the HTTP Session in your custom Seam authentication component. As long as your Principal object is prepopulated by your servlet filter it will work. If its not then you should return false in your seam authenticate method.

components.xml:

<security:identity authenticate-method="#{authBean.authenticate}" />

inside authenticate method:

ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();

Principal principal = context.getUserPrincipal();