I didn't have to move the jdbc/jetspeed resource element to
server.xml until I wanted to use the jetspeed login module from my
other application. I did get the login module working from the other
application, but found I had to move the following jars to shared/lib:
jetspeed-security
jetspeed-cm
spring
db-ojb
commons-lang
commons-pool
commons-dbcp
commons-codec
aopalliance
Richard
On 17 Sep 2005, at 6:45 pm, Aaron Evans wrote:
Richard Bounds <richard.bounds <at> riskgovernance.com> writes:
Thanks Aaron - that was spot on.
To be able to log in to Jetspeed and access my app I had to:
- Uncomment the SSO valve entry in the <host> section of server.xml
- Move the JAASRealm declaration from jetspeed.xml to server.xml
- Create a role in Jetspeed that corresponds to the role in the
<auth-
constraint> in my web.xml
I think that was it (although I've moved so many things around I
wouldn't be surprised if I've forgotten something). At the moment
I've disabled the login form within my application and will probably
just replace it with a message that instructs the user to log in via
Jetspeed (I'm assuming that I won't be able to use the Jetspeed login
module without moving a lot of jars into shared/lib).
Thanks again,
Richard
Sweet! I'm glad to hear you got that working because I will have to
tackle
this eventually as well.
One question though, did you not have to move the "jdbc/jetspeed
Resource"
element to the server.xml as well?
I believe you should be able to use a login form within your web
application
as well. Since the JAAS realm is at the container level and it is
working,
the appropriate jars must be available at the container level. It
stands to
reason that you should be able to create a login page from any webapp.
One pain in the butt with the tomcat SSO stuff is that you can't
really
provide a direct link to a login page or display the login form on
every page.
What you have to do is configure security constraints in your
webapp and then
configure a login-form in your webapp as well that names your login
JSP.
Then, when someone who has not authenticated themselves attempts to
navigate
(typically via a link) to a protected resource, they are directed
to the
configured login page. The nice thing is that once they login,
they are
directed straight to the protected resource they were attempting to
get to,
not to a default splash page. However, this comes at the cost of the
limitations above.
All this is to say that the jetspeed login pages are a little more
complicated because they have figured out a way to get around the
limitations above.
If you want to create an SSO login page for your webapp, here is
what you
need to do:
1. Configure a login-config element in your webapp's web.xml,
something like:
<login-config>
<auth-method>FORM</auth-method>
<realm-name>SSO Realm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/loginFailure.jsp</form-error-page>
</form-login-config>
</login-config>
2. Configure <security-constraint> elements to protect URIs in your
webapp
(which I assume you already have).
3. Your login.jsp should contain to form fields: j_username and
j_password
and the form should post to /j_security_check.
4. Create a link on a public page that will try to access a
protected URI.
That's about it. Clicking this link when not authenticated should
send
you to your login page. Once you login, assuming you are a member
of the role
which has access to the resource you attempted to hit, you should
be redirected
to that resource. If you are succesfully authenticated but not
authorized,
you will get a 403. So it is a good idea to configure an error-page
for
403 in your webapp so they get a nice looking page rather than the
tomcat
default.
I think that _should_ work in theory. Again, I will be tackling
this in the
future as well, so if you don't try it, I'll post back with my
results.
cheers,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
