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

[Shane Bryzak (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBSEAM-967?page=comments#action_12383835 ] 
            
Shane Bryzak 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). "

My point here was that users have a diverse range of requirements when it comes to security, and it is not possible for us to cater to the multitude of those requirements.  The Identity class in its design, is *absolutely* intended to be extended to create a more concrete security implementation, RuleBasedIdentity being one example.  Evidence for this is the hasPermission() method, which simply returns false in the base Identity class.

" "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?"

If you are overriding the hasRole() method (and delegating to the servlet API) then you don't need to call addRole() - the roles will come from the realm.

"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?"

It's not in the documentation because it simply hasn't been raised before.  This isn't a security-only recommendation though, it's a general principal in Seam that you can extend the core components.  This is the exact reason why we have the precedence attribute in the @Install annotation.  Perhaps we need to reinforce this principal in the documentation?

"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."

Originally I thought this issue would require a lot more integration with the Tomcat API (I actually wrote a bunch of realm-integration code in one of the early revision of Seam Security) however as you pointed out, it's really just a simple matter of delegating hasRole() etc to the ServletRequest.  Since this is the case and it really is a trivial thing to extend either Identity or RuleBasedIdentity to do this, there is really no point in introducing extra complexity to the Security API that most people won't need.  Just to clarify further, to actually implement this in Seam would involve some design changes (do we extend Identity or RuleBasedIdentity? either choice has implications).

"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?"

I'm more than happy to help you work through this Brad.  If you'd like to contact me directly, I think we can resolve these issues more effectively than through JIRA.

> 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