[
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