[
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