[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-967) JBoss Seam - Support authentication from a realm (on Tomcat)

Bradley Smith (JIRA) jira-events at lists.jboss.org
Mon Oct 22 09:33:06 EDT 2007


    [ http://jira.jboss.com/jira/browse/JBSEAM-967?page=comments#action_12383675 ] 
            
Bradley Smith commented on JBSEAM-967:
--------------------------------------

"security is a complicated area and the Identity" - huh?  I don't see what's complicated about this...  the authenticate() method is simply the Identity component analog to JAAS's login() method (or login() + commit() depending on how one chooses to perform authentication + authorization).  I would think that applying the rules at request time is where things get complicated.  What's complicated for me is trying to find the right balance of configuration in web.xml, pages.xml, and components.xml and implementation in authenticator (plus, now, possible custom identity) (that's 4-5 places/files).

"the authentication is being done elsewhere, then you don't need an Authenticator class. Just override Identity.authenticate() to not perform a JAAS login."  - so where should I put code to addRole()'s to Identity in an authenticator?  In Identity itself?

I've already explained my reluctance to extend a Seam core component - I simply don't trust that if I do so that my extension will compile (or behave the same) from release to release of Seam.  I also don't believe best practices / patterns are worked out for this stuff;  the next time someone changes a core component / .xml file / feature of Seam, all current knowledge / code based on the prior release will be void.  Despite claims that extending Identity is a recommended best practice in this discussion, I can't find anything in the documentation that suggests this as a technique.  I don't think there is an example of this in the Seam examples either.  How can something like this be 'best practice' if there is no attempt to document and promote it as a preferred technique in similar technical situations?

As it stands now, I'll have to basically start my work over to extend Identity and experiment with pages.xml and web.xml to find the right combination of configuration to work with a custom Identity component - this is frustrating.  Part of the trouble I've just been through in getting this to work is that the Seam identity component insists on trying to redirect to a login page - that's the not job of the Identity component if the container provides that service.  I don't understand the reluctance to at least look at making this change in Identity on your (Seam developer's) part.  After all, you asked me to file this issue and you would look into it.

Pardon my frustration but I really don't like doing things like this twice, thrice, etc. and I can see that I'm not making progress with the Seam team in this discussion.  Maybe in addition to your suggestion for extending Identity, you would care to provide an example of a working configuration for web.xml and pages.xml - something that doesn't require a login-page redirection to work?

Thanks,
Brad Smith

> JBoss Seam - Support authentication from a realm (on Tomcat)
> ------------------------------------------------------------
>
>                 Key: JBSEAM-967
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-967
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Bradley Smith
>         Assigned To: Shane Bryzak
>
> Please see discussion in the JBoss forum reference.
> The idea is to allow the Seam Identity (security) component to get the Principal from the HttpServletRequest and to delegate the hasRole() calls to the HttpServletRequest as well.  This is because, in my case, Tomcat has already forced the user to authenticate if necessary and the authentication, authorization information is available in the container's HttpServletRequest impl.
> Principal userPrincipal = httpServletRequest.getUserPrincipal();
> boolean hasRole(String roleName) {
>   return httpServletRequest.isUserInRole(roleName);
> }
> public String getUsername() {
>    return httpServletRequest.getRemoteUser();
> }
> public boolean isLoggedIn() {
>   return httpServletRequest.getUserPrincipal() != null;
> }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the seam-issues mailing list