Seam 1.1.5, authentication, and writing an authentication me

[gdaswani]

Looking at the SEAM 1.1.5 documentation, and the SeamLoginModule - it's able to call a custom method as long as it's

boolean (java.lang.String username, java.lang.String password, java.util.Set roles)

This only works for username/password type authentication.. It would be nice if there was an extended method signature that allowed passing in on the HttpServletRequest

ie.. Something like

boolean (HttpServletRequest request, HttpServletResponse response, Set roles);

the above is pretty useful when using it with single sign on systems (which usually pass tokens through a cookie, or a URL parameter, or even rig up some support for SPNEGO).

[shane.bryzak]

Since the security API uses JAAS for authentication it's totally extensible in this area. You simply need to provide your own LoginContext to Identity, i.e:

Identity.instance().authenticate(myLoginContext);

Your LoginContext can use whatever JAAS configuration you like.

[gavin.king]

"gdaswani" wrote:
Looking at the SEAM 1.1.5 documentation, and the SeamLoginModule - it's able to call a custom method as long as it's

boolean (java.lang.String username, java.lang.String password, java.util.Set roles)

This only works for username/password type authentication.. It would be nice if there was an extended method signature that allowed passing in on the HttpServletRequest

ie.. Something like

boolean (HttpServletRequest request, HttpServletResponse response, Set roles);

the above is pretty useful when using it with single sign on systems (which usually pass tokens through a cookie, or a URL parameter, or even rig up some support for SPNEGO).

What Shane said.

But also note that the method that is being called is just a method of an ordinary Seam component. You can inject any state you like, and you can call FacesContext.getCurrentInstance().getExternalContext() to mess with HTTP stuff.

In fact, I'm still not sure that the username, password, and set of roles shouldn't be *injected* into the Authenticator object, rather than passed as parameters. But this way requires less code, so I guess its better.

[shane.bryzak]

Or simply looked up from the Identity object.. ie Identity.instance().getUsername() / Identity.instance().getPassword(). And maybe returning the roles as a Set, or null if authentication failed.

[pmuir]

How about returning the roles as a set. If authentication failed the method should throw an exception (this is kind of consistent with the semantics for @Begin)

[gavin.king]

I think I like the following option best:

class Authenticator()
{

 @In Identity identity;

 public boolean authenticate()
 {
 String pw = identity.getPassword();
 String un = identity.getUsername();
 ....
 identity.setRoles(roles);
 return true;
 }


}

This is consistent with how Actor works:

class Authenticator()
{

 @In Identity identity;
 @In Actor actor;

 public boolean authenticate()
 {
 String pw = identity.getPassword();
 String un = identity.getUsername();
 ....
 identity.setRoles(roles);
 actory.setId(un);
 return true;
 }


}

[shane.bryzak]

I've updated CVS with these changes - the authenticator method now takes no parameters (and returns boolean as before). It's pretty much exactly how Gavin describes, except you call identity.addRole() for each role the user is a member of. The docs in CVS have been updated with these changes, so check there for exact details.