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
On 16 Sep 2005, at 4:13 pm, Aaron Evans wrote:
EDU COLL <educoll69 <at> hotmail.com> writes:
Richard: I have an implementation of an sso portlet in an J-M3
enviroment.
First you have to create, (in the Adminstrative part of Jetpeed,
sso-admin.psml) a sso Site (name and url). Then you select that
new site and
you will see in the sso Detail that you can create a mapping of a
portal
principal (admin for example) to a remote principal (you have also
to set
the remote password).
The 2 step is to create your own sso portlet:
In the jsp view asociated with this portlet, you must put a link
like that:
<a href="<portlet:actionURL/>" target="_blank">
MY SSO SITE
</a>
that not the best way to do, but it was the fast implementation
that i
found!
Enjoy it. Eduardo Coll.
Interesting approach. However the username and password will be in
clear text
in the URL of the redirect (of course using SSL will help mitigate
that risk).
But it shouldn't be so difficult if the webapps are in the same
container.
I wonder if the problem is that tomcat's SSO requires an
authentication realm
at the container level while jetspeed's is at the webapp level? I
have used
a realm at the container (engine) level in tomcat before to achieve
SSO
between two webapps and this is how it was done. Perhaps if we
somehow moved
the realm configuration to this level it would work. This would
assume that
you were always authenticating against jetspeed's JAAS realm.
I believe that the rough steps would be something like:
1. Move the jdbc/jetspeed Resource from
$CATALINA_HOME/conf/Catalina/localhost/<jetspeed_contxt>.xml to
$CATALINA_HOME/conf/server.xml in a GlobalNamingResources element
under the
Server element. Should probably then put a ResourceLink element in
the
jetspeed context config referring to the global one.
2. Move the Realm configuration from
$CATALINA_HOME/conf/Catalina/localhost/<jetspeed_contxt>.xml to the
localhost
Engine element in $CATALINA_HOME/conf/server.xml.
3. Sort out which of jetspeeds jars would need to move to shared/
lib (if
any).
4. Normally for tomcat Realm/SSO, you have to post to /
j_security_check
and the params have to be j_username and j_password. Jetspeed's
login comes
from the security webapp and it looks as though they are using
org.apache.jetspeed.login.username and
org.apache.jetspeed.login.password
and are posting to /portal/login/proxy. However, at the end of the
day, you
get redirected to /portal/login/redirector which contains an onLoad
java script
to do a post to j_security_check with the correct params.
So, in *theory*, I think something like this should work. Then
again, I
could be off my rocker.
In any event I will have to tackle this at some point when I get
further along
in my project as I will need SSO with another webapp in the tomcat
container
as well. So please post any solutions you find to this. If I get
around to
trying my hair-brained scheme, I'll post back with the 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]
