Hi guys,
thanks Jacob for your notes.
I thought 'bout this solution too, but the real problem is the UserPrincipal
reference, not the roles. There is a method in the identity object to add roles but no way
to set a pre-existing Subject or Principal. That's the problem.
The use of java security APIs in web apps is tricky. You are not supposed to have a login
form where the user can authenticate himself beforehand. You can only configure a form to
be presented when he tries to access a protected / secured resource of your app, and only
through this form the container is aware that the authentication occurred and appends this
information in every request from this point on. You can access this information using
request.getUserPrincipal() (not Seam approach) or org.jboss.seam.core.UserPrincipal. Our
solution is to create a form the user can fill and the action of this form redirects the
request to a protected page "/private/abcd.seam" that only change the
browser's location object to "/public/abcd.seam". In my web.xml I have:
| ...
|
| <security-constraint>
| <web-resource-collection>
| <web-resource-name>My Private Pages</web-resource-name>
| <url-pattern>/private/*</url-pattern>
| </web-resource-collection>
| <auth-constraint>
| <role-name>*</role-name>
| </auth-constraint>
| </security-constraint>
|
| ...
|
| <login-config>
| <auth-method>FORM</auth-method>
| <realm-name>myRealmName</realm-name>
| <form-login-config>
| <form-login-page>/jaasLogin.seam</form-login-page>
| <form-error-page>/jaasLoginError.seam</form-error-page>
| </form-login-config>
| </login-config>
|
| ...
So, when I redirect the request to "/private/abcd.seam", the container
automatically sends "/private/jaasLogin.seam" to the user. This page content
does an immediate form submission using the information the user supplied im my official
login form:
| <body onload="document.forms[0].submit();">
| <form method="post" action="j_security_check">
| <input type="hidden" name="j_username"
id="j_username" value="#{user.username}" />
| <input type="hidden" name="j_password"
id="j_password" value="#{user.password}" />
| </form>
| </body>
|
This way, my LoginModule is invoked and the authentication happens as it is supposed to
and when the private page is finally reached it redirects the user to the real "after
Login page" of my initial web app. From this moment on, the user has access granted
to all my "/private/*" pages. As I configured my JBoss to use SSO, all my apps
will receive the userPrincipal of this first app, that mainly configures the public and
private options of all other apps. So all my apps see the user as already authenticated,
granting access to their "/private/*" pages too. In these pages I want to use
#{s:hasRole} and #{s:hasPermission} and @Restrict to further define user's
permissions.
My problem is that as I can't push this userPrincipal into the identity object, a
pre-condition to use Seam permission checking, I am being forced to authenticate the user
again, configuring the identity in the components.xml file to use the same realm declared
im my web.xml:
| <security:identity jaas-config-name="myRealmName" />
I end up with 2 Principal objects I must keep in sync. I think that would be great if Seam
was able to "detect" that there is an already authenticated user information
available (when using JAAS, of course) and use it or, at least, allow the developer to do
that.
I asked for an opinion from the development team but until now no one answered. Maybe my
approach is completely wrong and I should be doing something completely different. Maybe
it is a completely absurd idea change the way Seam's security framework was designed.
But as far as I can see with my limited view of the JAAS support in Seam, it seems SSO was
not considered.
Sorry if this message is too long. Sorry if I insist, but I really would like to hear from
the development team about this. :)
Thanks.
Gilson
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088356#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...