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

Pete Muir (JIRA) jira-events at lists.jboss.org
Fri Oct 19 08:33:03 EDT 2007


    [ http://jira.jboss.com/jira/browse/JBSEAM-967?page=comments#action_12383423 ] 
            
Pete Muir commented on JBSEAM-967:
----------------------------------

Brad, I can't comment for Shane but here is my 2c.

"First, is extending a Seam component class a recommended pattern / best practice?"

Yes.

"The approach of creating an authenticator seems better / cleaner."

Authenticator is specifically for authentication, whilst Identity is for authorization - sounds like you need both...

"If I do extend Identity, how do I make my Identity impl THE identity component for my Seam applications (what changes in the class annotations)? "

@Name("org.jboss.seam.security.identity")

should be enough (make sure you have no references to <security:identity /> in components.xml, configuration would need to be via <component name="org.jboss.seam.security.identity">...)

"isn't it just as trivial to leave a version of the old annotations in their original packages along with some kind of deprecation warning? What's the guarantee that Identity isn't going to get a similar refactoring in methods or packaging?"

Well we could have done, but this would have required significant changes to Seam to check for both annotations.  For this level of refactoring to happen to core the another major bump in version number would have to occur (i.e. its not going to happen for quite a while!). But lets not have a discussion on this issue about Seam versioning ;)

"One more comment, when I change Identity, I'm still required to create an authenticator, so now, with a changed Identity, I have to maintain code in two classes - both the Identity and the authenticator. Currently I only have an authenticator to main. Isn't it also trivial to add an attribute to the Identity's configuration that 'turns on' this behavior in Identity?

e.g.:

<security:identity authenticate-method="#{ssoAuthenticator.authenticate}"/ obtainUserFromRequest="true">

P.S. - After having created an authenticator with loads the roles into Identity, I'm less interested in delegating the hasRole() call to the servlet request, because I would like to take advantage of the EL stuff (e.g. #{s:hasRole('aummaint')} ). "

As above, identity and authenticator are for authorization and authentication separately. 

> 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