A
Arved Sandstrom
If this could happen to me, it's happened to others, and probably may
come up yet again in future. If it's in the documentation for the Sun App
Server admin console (9.1), and I sure looked after I figured out the
problem, I haven't found it yet. It's also somewhat counter-intuitive.
Basically it boils down to the Assign Group field on a file realm editor
page. Unless you've figured out what this is for (I haven't), leave it
blank. Only specify your groups when actually creating or editing a
principal. If you do put in groups (I assumed this field was for all
_possible_ groups) in the Assign Group field, it no longer matters what
groups you put your principals in, or what the mapping in sun-web.xml is,
or anything...every authenticated user will end up being in every role
you've specified.
It took me a while to figure this out. I haven't ever (I believe) used
container-managed form authentication with JSF (every app I've worked on
uses programmatic login), and I thought I'd experiment with the
'j_security_check' standard, Glassfish, ICEFaces and Facelets. Getting
this to work is easy enough, and one can use JSF for the login page and
the login error page...you just have to use plain-vanilla HTML for the
login _form_ itself (the ID mangling issue). So relatively quickly I was
authenticating properly. That's when things got hateful.
I was aware that JSF and container-based authentication/authorization are
a bit shaky, although a lot of that is kerfuffle over people wanting the
login _form_ to be JSF, so they can validate and all that good stuff,
which I don't myself understand (*). But there's enough Google material
on other potential problems involving JSF and container-managed security
to make one sort of expect problems. It was only after about 3
hours...and ripping out ICEFaces and then Facelets, and making all manner
of configuration tweaks...that I finally tried this. Only a serendipitous
println gave me a glimmer.
For anyone interested in ICEFaces I'm pleased to report that the
"renderedOnUserRole" attribute on ICEFaces tags works just fine in this
container-managed security scenario. There are plenty of reports to
suggest that it does not, but I'm guessing that's with specific tags. I
normally use ICEFaces components sparingly, and use a Map managed bean
instead that can be used in EL to examine security roles. But it's nice
to see that the ICEFaces attribute works.
Hope this saves someone a few hours of hair-pulling and cursing.
AHS
* As in, why exactly? After all, if the user has a wrong username or
password (including empty fields), you do have a login error page. Just
make the messages there informative. Of course, if you intend to
authenticate in the code, fill your boots...make it a JSF form and
dispense with standard form authentication. What I don't understand is
folks who want to do both.
come up yet again in future. If it's in the documentation for the Sun App
Server admin console (9.1), and I sure looked after I figured out the
problem, I haven't found it yet. It's also somewhat counter-intuitive.
Basically it boils down to the Assign Group field on a file realm editor
page. Unless you've figured out what this is for (I haven't), leave it
blank. Only specify your groups when actually creating or editing a
principal. If you do put in groups (I assumed this field was for all
_possible_ groups) in the Assign Group field, it no longer matters what
groups you put your principals in, or what the mapping in sun-web.xml is,
or anything...every authenticated user will end up being in every role
you've specified.
It took me a while to figure this out. I haven't ever (I believe) used
container-managed form authentication with JSF (every app I've worked on
uses programmatic login), and I thought I'd experiment with the
'j_security_check' standard, Glassfish, ICEFaces and Facelets. Getting
this to work is easy enough, and one can use JSF for the login page and
the login error page...you just have to use plain-vanilla HTML for the
login _form_ itself (the ID mangling issue). So relatively quickly I was
authenticating properly. That's when things got hateful.
I was aware that JSF and container-based authentication/authorization are
a bit shaky, although a lot of that is kerfuffle over people wanting the
login _form_ to be JSF, so they can validate and all that good stuff,
which I don't myself understand (*). But there's enough Google material
on other potential problems involving JSF and container-managed security
to make one sort of expect problems. It was only after about 3
hours...and ripping out ICEFaces and then Facelets, and making all manner
of configuration tweaks...that I finally tried this. Only a serendipitous
println gave me a glimmer.
For anyone interested in ICEFaces I'm pleased to report that the
"renderedOnUserRole" attribute on ICEFaces tags works just fine in this
container-managed security scenario. There are plenty of reports to
suggest that it does not, but I'm guessing that's with specific tags. I
normally use ICEFaces components sparingly, and use a Map managed bean
instead that can be used in EL to examine security roles. But it's nice
to see that the ICEFaces attribute works.
Hope this saves someone a few hours of hair-pulling and cursing.
AHS
* As in, why exactly? After all, if the user has a wrong username or
password (including empty fields), you do have a login error page. Just
make the messages there informative. Of course, if you intend to
authenticate in the code, fill your boots...make it a JSF form and
dispense with standard form authentication. What I don't understand is
folks who want to do both.