You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Aaron Evans <aa...@gmail.com> on 2008/09/11 19:37:12 UTC
Jetspeed SSO
Hey all,
I'm finally going to get rolling with trying to tie together some of
our various web-based service offerings into a single UI under
jetspeed 2.
So I'm thinking of looking at some of the SSO portlets like
SSOWebContent or the IFrame one or something similar.
But, I'm seeking some advice because there's a catch.
Here's the deal: we've successfully gotten all of our web application
service offerings authenticating against a common LDAP server, the
same LDAP server that we authenticate against for jetspeed..
So, the user names and passwords for accessing these web applications
will be precisely the same ones as they are for accessing jetspeed.
Thus, I want to be able to setup some kind of SSO portlet that will
point at a given URL (which I would like to vary a bit dynamically
based on some user data) and use the user's jetspeed userID and
password for the back-end SSO authentication.
Now, our passwords are not stored in clear text but rather a SHA based hash.
So, I was thinking that if I modified the authentication mechanism in
jetspeed to capture the submitted password value at login and store it
in a session variable, I could then use that value combined with the
principal's name for the SSO authentication.
Users should not be required to set their userID and password for a
given remote site themselves, we want to hide all of this from them.
Nor can they modify the URL we want to send them to but as I said, the
URL will vary by customer (which is an LDAP/jetspeed group
incidentally).
Obviously I would have to extend one or more of the SSO portlets to do this.
Anyway, I'm just looking for some general advice before I dive too
deep into this to see if anyone can think of a simpler way to achieve
something like this.
cheers,
aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Sep 29, 2008, at 6:22 PM, Aaron Evans wrote:
>> We do support bidirectional encoding, but I suspect your passwords
>> are
>> already generated. For future reference see security-spi-atn.xml:
>>
>>
>> <!-- A Two-way encoding password service which also implements
>> CredentialPasswordEncoder
>> this Service can be used instead of for example the default
>> provided
>> MessageDigestCredentialPasswordEncoder
>> <bean id="org.apache.jetspeed.security.PasswordEncodingService"
>> name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
>> class="org.apache.jetspeed.security.spi.impl.PBEPasswordService">
>> <constructor-arg index="0">
>> <!- secret PBE key password ->
>> <value>********</value>
>> </constructor-arg>
>> </bean>
>> -->
>>
>
> Yes, our passwords are already generated. But further still, we are
> using a one-way hash algorithm (SHA-1), so this wouldn't work anyway,
> would it?
>
Sorry, once you use the one-way you are stuck with it
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by Aaron Evans <aa...@gmail.com>.
Comments below...
On Mon, Sep 29, 2008 at 12:09 PM, David Sean Taylor
<dt...@onehippo.com> wrote:
>
> dtaylor@onehippo.com www.onehippo.com
> San Francisco - Hippo USA Inc. 101 H Street, Suite Q Petaluma CA 94952-3329
> +1 (877) 41-HIPPO
> Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
>
>
>
> On Sep 26, 2008, at 2:16 AM, Aaron Evans wrote:
>
>> Thanks for the tips David, most helfpul.
>>
>> Quick question before I start on general ramblings:
>>
>> If I did want to programmatically set some user-specific portlet
>> preferences, would I do that with the
>> org.apache.jetspeed.prefs.PreferencesProvider component (defined in
>> prefs.xml)?
>
> Yes. Just want to comment that we are refactoring the Prefs for 2.2 release
> (scheduled for beginning of November, ApacheCon)
>
Ok, I'll keep that in mind.
>>
>> Here is an update on my progress for anyone who might find themselves
>> in a similar situation...
>>
>> So, goal #1 was accomplished and that was to capture the clear text
>> password in the Subject's private credentials.
>>
>> This was much harder than it sounds because normally the Credentials
>> are populated by the CredentialHandler via the UserManager. But the
>> method signature only provides the principal username, not the
>> submitted password. Since the password is stored in SHA-1 encoding in
>> LDAP, my implementation has no way to lookup the clear text password.
>> The best it can do is to look up the hashed value and use that.
>>
> We do support bidirectional encoding, but I suspect your passwords are
> already generated. For future reference see security-spi-atn.xml:
>
>
> <!-- A Two-way encoding password service which also implements
> CredentialPasswordEncoder
> this Service can be used instead of for example the default provided
> MessageDigestCredentialPasswordEncoder
> <bean id="org.apache.jetspeed.security.PasswordEncodingService"
> name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
> class="org.apache.jetspeed.security.spi.impl.PBEPasswordService">
> <constructor-arg index="0">
> <!- secret PBE key password ->
> <value>********</value>
> </constructor-arg>
> </bean>
> -->
>
Yes, our passwords are already generated. But further still, we are
using a one-way hash algorithm (SHA-1), so this wouldn't work anyway,
would it?
>
>> There isn't really a good place where you have access to both the
>> Subject being constructed and the clear text password. The
>> LoginModule *would* be that place but that Subject is discarded. The
>> permanent (session) subject is created in the SecurityValve as you
>> said.
>
> We are no longer discarding the Subject, this was fixed for the 2.2 release:
>
> https://issues.apache.org/jira/browse/JS2-238
>
> warning: only tested with Tomcat 5.5
>
Ah, excellent. I'll be able to simplify the whole thing and override
less components.
>>
>>
>> So, I had to override the LoginRedirectorServlet so that it wouldn't
>> erase the password value from the session immediately. Instead, later
>> in the pipeline I get the Subject out of the session and create a new
>> one that contains private credentials with the clear text password and
>> stuff that back in the session replacing the other.
>>
>> So now all my portlets have access to the subject and the clear text
>> password (it was accessible using the API calls you specified).
>>
>> So now I'm going to experiment with stuffing the creds in the SSO
>> store as you suggest. However, I think I'll likely run into problems
>> since this is not functioning from the SSO Administration portlets as
>> I said in a previous post. I think it doesn't work if you don't use
>> the default SPI implementation. Anyhow, I should know more in the
>> next few days when I try this out, perhaps I can pinpoint the problem.
>>
>
> I would be interested to know if there is a bug there
> Note that as a part of the security refactoring in 2.2 we are also in the
> process of correcting the SSO model
>
I will try to test this out and let you know as soon as I can.
>
>> I think I shall also experiment with programmatically and preemptively
>> populating user preferences for dedicated SSO portlet instances and
>> see how that goes as well...
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by David Sean Taylor <dt...@onehippo.com>.
dtaylor@onehippo.com www.onehippo.com
San Francisco - Hippo USA Inc. 101 H Street, Suite Q Petaluma CA
94952-3329 +1 (877) 41-HIPPO
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466
On Sep 26, 2008, at 2:16 AM, Aaron Evans wrote:
> Thanks for the tips David, most helfpul.
>
> Quick question before I start on general ramblings:
>
> If I did want to programmatically set some user-specific portlet
> preferences, would I do that with the
> org.apache.jetspeed.prefs.PreferencesProvider component (defined in
> prefs.xml)?
Yes. Just want to comment that we are refactoring the Prefs for 2.2
release (scheduled for beginning of November, ApacheCon)
>
> Here is an update on my progress for anyone who might find themselves
> in a similar situation...
>
> So, goal #1 was accomplished and that was to capture the clear text
> password in the Subject's private credentials.
>
> This was much harder than it sounds because normally the Credentials
> are populated by the CredentialHandler via the UserManager. But the
> method signature only provides the principal username, not the
> submitted password. Since the password is stored in SHA-1 encoding in
> LDAP, my implementation has no way to lookup the clear text password.
> The best it can do is to look up the hashed value and use that.
>
We do support bidirectional encoding, but I suspect your passwords are
already generated. For future reference see security-spi-atn.xml:
<!-- A Two-way encoding password service which also implements
CredentialPasswordEncoder
this Service can be used instead of for example the default
provided MessageDigestCredentialPasswordEncoder
<bean id="org.apache.jetspeed.security.PasswordEncodingService"
name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
class="org.apache.jetspeed.security.spi.impl.PBEPasswordService">
<constructor-arg index="0">
<!- secret PBE key password ->
<value>********</value>
</constructor-arg>
</bean>
-->
> There isn't really a good place where you have access to both the
> Subject being constructed and the clear text password. The
> LoginModule *would* be that place but that Subject is discarded. The
> permanent (session) subject is created in the SecurityValve as you
> said.
We are no longer discarding the Subject, this was fixed for the 2.2
release:
https://issues.apache.org/jira/browse/JS2-238
warning: only tested with Tomcat 5.5
>
>
> So, I had to override the LoginRedirectorServlet so that it wouldn't
> erase the password value from the session immediately. Instead, later
> in the pipeline I get the Subject out of the session and create a new
> one that contains private credentials with the clear text password and
> stuff that back in the session replacing the other.
>
> So now all my portlets have access to the subject and the clear text
> password (it was accessible using the API calls you specified).
>
> So now I'm going to experiment with stuffing the creds in the SSO
> store as you suggest. However, I think I'll likely run into problems
> since this is not functioning from the SSO Administration portlets as
> I said in a previous post. I think it doesn't work if you don't use
> the default SPI implementation. Anyhow, I should know more in the
> next few days when I try this out, perhaps I can pinpoint the problem.
>
I would be interested to know if there is a bug there
Note that as a part of the security refactoring in 2.2 we are also in
the process of correcting the SSO model
> I think I shall also experiment with programmatically and preemptively
> populating user preferences for dedicated SSO portlet instances and
> see how that goes as well...
>
Re: Jetspeed SSO
Posted by Aaron Evans <aa...@gmail.com>.
Thanks for the tips David, most helfpul.
Quick question before I start on general ramblings:
If I did want to programmatically set some user-specific portlet
preferences, would I do that with the
org.apache.jetspeed.prefs.PreferencesProvider component (defined in
prefs.xml)?
Here is an update on my progress for anyone who might find themselves
in a similar situation...
So, goal #1 was accomplished and that was to capture the clear text
password in the Subject's private credentials.
This was much harder than it sounds because normally the Credentials
are populated by the CredentialHandler via the UserManager. But the
method signature only provides the principal username, not the
submitted password. Since the password is stored in SHA-1 encoding in
LDAP, my implementation has no way to lookup the clear text password.
The best it can do is to look up the hashed value and use that.
There isn't really a good place where you have access to both the
Subject being constructed and the clear text password. The
LoginModule *would* be that place but that Subject is discarded. The
permanent (session) subject is created in the SecurityValve as you
said.
So, I had to override the LoginRedirectorServlet so that it wouldn't
erase the password value from the session immediately. Instead, later
in the pipeline I get the Subject out of the session and create a new
one that contains private credentials with the clear text password and
stuff that back in the session replacing the other.
So now all my portlets have access to the subject and the clear text
password (it was accessible using the API calls you specified).
So now I'm going to experiment with stuffing the creds in the SSO
store as you suggest. However, I think I'll likely run into problems
since this is not functioning from the SSO Administration portlets as
I said in a previous post. I think it doesn't work if you don't use
the default SPI implementation. Anyhow, I should know more in the
next few days when I try this out, perhaps I can pinpoint the problem.
I think I shall also experiment with programmatically and preemptively
populating user preferences for dedicated SSO portlet instances and
see how that goes as well...
-aaron
On Wed, Sep 24, 2008 at 4:51 PM, David Sean Taylor
<da...@bluesunrise.com> wrote:
>
> On Sep 24, 2008, at 11:40 AM, Aaron Evans wrote:
>
>> Thanks for the response David.
>>
>> Is it possible to get the Subject within other portlet applications
>> (besides the jetspeed application)?
>
> We create the Subject in the Security Valve. So what you could do is get it
> via the requestContext.getSubject() method in your own valve, placed after
> the security valve in the pipeline.
>
>>
>>
>> Are the SSOPortlets intended to be deployed under the jetspeed context?
>
> no
>
>>
>>
>> I would prefer to extend the SSOPortlets and deploy them in another app.
>>
>
> Getting the Subject on the request in another app is also possible. Just get
> the request context from your request object such as in a JSP
>
> <%@ page import="org.apache.jetspeed.request.RequestContext"%>
>
> <c_rt:set var="requestContext"
> value="<%=request.getAttribute(RequestContext.REQUEST_PORTALENV)%>"/>
> <c:set var="mySubject" value="${requestContext.subject}"/>
>
>
>> If I can't get at the Subject in another app, I suppose I could always
>> extend the UserManagerImpl and have it stuff the password in the
>> user's preferences in the getUser method.
>>
>> In fact, maybe that's the easiest way to go?
>
> Well, I would consider stuffing in the SSO store
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Sep 24, 2008, at 11:40 AM, Aaron Evans wrote:
> Thanks for the response David.
>
> Is it possible to get the Subject within other portlet applications
> (besides the jetspeed application)?
We create the Subject in the Security Valve. So what you could do is
get it via the requestContext.getSubject() method in your own valve,
placed after the security valve in the pipeline.
>
>
> Are the SSOPortlets intended to be deployed under the jetspeed
> context?
no
>
>
> I would prefer to extend the SSOPortlets and deploy them in another
> app.
>
Getting the Subject on the request in another app is also possible.
Just get the request context from your request object such as in a JSP
<%@ page import="org.apache.jetspeed.request.RequestContext"%>
<c_rt:set var="requestContext" value="<
%=request.getAttribute(RequestContext.REQUEST_PORTALENV)%>"/>
<c:set var="mySubject" value="${requestContext.subject}"/>
> If I can't get at the Subject in another app, I suppose I could always
> extend the UserManagerImpl and have it stuff the password in the
> user's preferences in the getUser method.
>
> In fact, maybe that's the easiest way to go?
Well, I would consider stuffing in the SSO store
Re: Jetspeed SSO
Posted by Aaron Evans <aa...@gmail.com>.
Thanks for the response David.
Is it possible to get the Subject within other portlet applications
(besides the jetspeed application)?
Are the SSOPortlets intended to be deployed under the jetspeed context?
I would prefer to extend the SSOPortlets and deploy them in another app.
If I can't get at the Subject in another app, I suppose I could always
extend the UserManagerImpl and have it stuff the password in the
user's preferences in the getUser method.
In fact, maybe that's the easiest way to go?
On Tue, Sep 23, 2008 at 10:42 PM, David Sean Taylor
<da...@bluesunrise.com> wrote:
> Sorry for the late response. I had a email server problem and lost a lot of
> my lists emails. Just getting things pieced back together, but I don't seem
> to be receiving my on posts from this afternoon. see response below
>
> On Sep 11, 2008, at 10:37 AM, Aaron Evans wrote:
>
>> Hey all,
>>
>> I'm finally going to get rolling with trying to tie together some of
>> our various web-based service offerings into a single UI under
>> jetspeed 2.
>>
>> So I'm thinking of looking at some of the SSO portlets like
>> SSOWebContent or the IFrame one or something similar.
>>
>> But, I'm seeking some advice because there's a catch.
>>
>> Here's the deal: we've successfully gotten all of our web application
>> service offerings authenticating against a common LDAP server, the
>> same LDAP server that we authenticate against for jetspeed..
>>
>> So, the user names and passwords for accessing these web applications
>> will be precisely the same ones as they are for accessing jetspeed.
>>
>> Thus, I want to be able to setup some kind of SSO portlet that will
>> point at a given URL (which I would like to vary a bit dynamically
>> based on some user data) and use the user's jetspeed userID and
>> password for the back-end SSO authentication.
>>
>> Now, our passwords are not stored in clear text but rather a SHA based
>> hash.
>>
>> So, I was thinking that if I modified the authentication mechanism in
>> jetspeed to capture the submitted password value at login and store it
>> in a session variable, I could then use that value combined with the
>> principal's name for the SSO authentication.
>>
>> Users should not be required to set their userID and password for a
>> given remote site themselves, we want to hide all of this from them.
>> Nor can they modify the URL we want to send them to but as I said, the
>> URL will vary by customer (which is an LDAP/jetspeed group
>> incidentally).
>>
>> Obviously I would have to extend one or more of the SSO portlets to do
>> this.
>>
>> Anyway, I'm just looking for some general advice before I dive too
>> deep into this to see if anyone can think of a simpler way to achieve
>> something like this.
>>
> The SSO Component allows you to store credentials associating with a user
> (or group of users) and a site(URL).
> I think if you got the password out of the Jetspeed Subject, couldn't you
> just "authenticate" against your LDAP using it
>
> You mentioned the SSOWebContent portlet. It supports several kinds of
> authentication:
>
> Basic authentication
> is the default and can be supported effectively without even setting
> sso.type Just by providing credentials for the domain. The credentials will
> not be sent preemptively, but if a 401 request is returned for Basic
> authentication, it will be handled properly. Tis is equivalent to setting
> sso.type=basic (or sso.type=html (old - now deprecated in favor of calling
> it basic). if you set sso.type=basic.preemptive, it will send the
> credentials preemptively.
>
> URL authentication
> (query args) is supported as sso.type=url or sso.type=url.base64. By
> definition, this type of authentication is preemptive, so no distinction is
> made there.
>
> Form-authentication
> is supported with sso.type=form (which is equivalent to sso.type=form.post -
> you can also specify sso.type=form.get, if GET protocol is used on the login
> form). This form also requires a bunch of other data ( e.g. the action URL,
> other args, names of the fields for credentials, etc.). All of this is in an
> example that is in the demo portlet.xml. Form-based authentication is also
> considred "preemptive", in that it authenticates before any other content is
> read. However, it only does it once. If it succeeds, all should be well. If
> it fails, the user will have to login by hand (since the initial content URL
> will cause a redirect to the login page).
>
>
> The following preferences can be used with the SSO IFrame Portlet in
> addition to the standard IFrame preferences
>
> Preference Usage
> sso.type The type of Single signon authentication. Valid values: form
> | basic | basic.preemptive | url | url.base64
> sso.url.Credential The name of the credential input field or parameter
> sso.url.Principal The name of the user name input field or parameter
> SSO Principal The actual user name
> SSO Credential The actual crendential value
>
> Examples of extending the SSOWebContentPortlet, see 2.1.3: SSOTicketPortlet:
>
> public class SSOTicketPortlet extends SSOWebContentPortlet
>
> It might be interesting to extend the SSO portlets to use the current
> Jetspeed credentials for the user, I guess I never thought of that case
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by David Sean Taylor <da...@bluesunrise.com>.
Sorry for the late response. I had a email server problem and lost a
lot of my lists emails. Just getting things pieced back together, but
I don't seem to be receiving my on posts from this afternoon. see
response below
On Sep 11, 2008, at 10:37 AM, Aaron Evans wrote:
> Hey all,
>
> I'm finally going to get rolling with trying to tie together some of
> our various web-based service offerings into a single UI under
> jetspeed 2.
>
> So I'm thinking of looking at some of the SSO portlets like
> SSOWebContent or the IFrame one or something similar.
>
> But, I'm seeking some advice because there's a catch.
>
> Here's the deal: we've successfully gotten all of our web application
> service offerings authenticating against a common LDAP server, the
> same LDAP server that we authenticate against for jetspeed..
>
> So, the user names and passwords for accessing these web applications
> will be precisely the same ones as they are for accessing jetspeed.
>
> Thus, I want to be able to setup some kind of SSO portlet that will
> point at a given URL (which I would like to vary a bit dynamically
> based on some user data) and use the user's jetspeed userID and
> password for the back-end SSO authentication.
>
> Now, our passwords are not stored in clear text but rather a SHA
> based hash.
>
> So, I was thinking that if I modified the authentication mechanism in
> jetspeed to capture the submitted password value at login and store it
> in a session variable, I could then use that value combined with the
> principal's name for the SSO authentication.
>
> Users should not be required to set their userID and password for a
> given remote site themselves, we want to hide all of this from them.
> Nor can they modify the URL we want to send them to but as I said, the
> URL will vary by customer (which is an LDAP/jetspeed group
> incidentally).
>
> Obviously I would have to extend one or more of the SSO portlets to
> do this.
>
> Anyway, I'm just looking for some general advice before I dive too
> deep into this to see if anyone can think of a simpler way to achieve
> something like this.
>
The SSO Component allows you to store credentials associating with a
user (or group of users) and a site(URL).
I think if you got the password out of the Jetspeed Subject, couldn't
you just "authenticate" against your LDAP using it
You mentioned the SSOWebContent portlet. It supports several kinds of
authentication:
Basic authentication
is the default and can be supported effectively without even setting
sso.type Just by providing credentials for the domain. The credentials
will not be sent preemptively, but if a 401 request is returned for
Basic authentication, it will be handled properly. Tis is equivalent
to setting sso.type=basic (or sso.type=html (old - now deprecated in
favor of calling it basic). if you set sso.type=basic.preemptive, it
will send the credentials preemptively.
URL authentication
(query args) is supported as sso.type=url or sso.type=url.base64. By
definition, this type of authentication is preemptive, so no
distinction is made there.
Form-authentication
is supported with sso.type=form (which is equivalent to
sso.type=form.post - you can also specify sso.type=form.get, if GET
protocol is used on the login form). This form also requires a bunch
of other data ( e.g. the action URL, other args, names of the fields
for credentials, etc.). All of this is in an example that is in the
demo portlet.xml. Form-based authentication is also considred
"preemptive", in that it authenticates before any other content is
read. However, it only does it once. If it succeeds, all should be
well. If it fails, the user will have to login by hand (since the
initial content URL will cause a redirect to the login page).
The following preferences can be used with the SSO IFrame Portlet in
addition to the standard IFrame preferences
Preference Usage
sso.type The type of Single signon authentication. Valid values: form
| basic | basic.preemptive | url | url.base64
sso.url.Credential The name of the credential input field or parameter
sso.url.Principal The name of the user name input field or parameter
SSO Principal The actual user name
SSO Credential The actual crendential value
Examples of extending the SSOWebContentPortlet, see 2.1.3:
SSOTicketPortlet:
public class SSOTicketPortlet extends SSOWebContentPortlet
It might be interesting to extend the SSO portlets to use the current
Jetspeed credentials for the user, I guess I never thought of that case
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by Aaron Evans <aa...@gmail.com>.
Thank you very much!
On Tue, Sep 16, 2008 at 6:41 PM, Niels van Kampenhout
<n....@onehippo.com> wrote:
> Aaron Evans wrote:
>>
>> Ok,
>>
>> Can someone at least point me to where in the source repository the
>> source is kept for these portlets:
>>
>> org.apache.jetspeed.portlet.SSOWebContentPortlet
>> org.apache.jetspeed.portlet.SSOIFramePortlet
>
> For trunk (2.2):
>
> http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/components/jetspeed-web-content/src/main/java/org/apache/jetspeed/portlet/SSOWebContentPortlet.java
> http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/components/jetspeed-web-content/src/main/java/org/apache/jetspeed/portlet/SSOIFramePortlet.java
>
> For 2.1.3:
>
> http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3/components/web-content/src/java/org/apache/jetspeed/portlet/SSOWebContentPortlet.java
> http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3/components/web-content/src/java/org/apache/jetspeed/portlet/SSOIFramePortlet.java
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by Niels van Kampenhout <n....@onehippo.com>.
Aaron Evans wrote:
> Ok,
>
> Can someone at least point me to where in the source repository the
> source is kept for these portlets:
>
> org.apache.jetspeed.portlet.SSOWebContentPortlet
> org.apache.jetspeed.portlet.SSOIFramePortlet
For trunk (2.2):
http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/components/jetspeed-web-content/src/main/java/org/apache/jetspeed/portlet/SSOWebContentPortlet.java
http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/components/jetspeed-web-content/src/main/java/org/apache/jetspeed/portlet/SSOIFramePortlet.java
For 2.1.3:
http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3/components/web-content/src/java/org/apache/jetspeed/portlet/SSOWebContentPortlet.java
http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/branches/JETSPEED-2.1.3/components/web-content/src/java/org/apache/jetspeed/portlet/SSOIFramePortlet.java
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Jetspeed SSO
Posted by Aaron Evans <aa...@gmail.com>.
Ok,
Can someone at least point me to where in the source repository the
source is kept for these portlets:
org.apache.jetspeed.portlet.SSOWebContentPortlet
org.apache.jetspeed.portlet.SSOIFramePortlet
thanks in advance,
aaron
On Thu, Sep 11, 2008 at 1:37 PM, Aaron Evans <aa...@gmail.com> wrote:
> Hey all,
>
> I'm finally going to get rolling with trying to tie together some of
> our various web-based service offerings into a single UI under
> jetspeed 2.
>
> So I'm thinking of looking at some of the SSO portlets like
> SSOWebContent or the IFrame one or something similar.
>
> But, I'm seeking some advice because there's a catch.
>
> Here's the deal: we've successfully gotten all of our web application
> service offerings authenticating against a common LDAP server, the
> same LDAP server that we authenticate against for jetspeed..
>
> So, the user names and passwords for accessing these web applications
> will be precisely the same ones as they are for accessing jetspeed.
>
> Thus, I want to be able to setup some kind of SSO portlet that will
> point at a given URL (which I would like to vary a bit dynamically
> based on some user data) and use the user's jetspeed userID and
> password for the back-end SSO authentication.
>
> Now, our passwords are not stored in clear text but rather a SHA based hash.
>
> So, I was thinking that if I modified the authentication mechanism in
> jetspeed to capture the submitted password value at login and store it
> in a session variable, I could then use that value combined with the
> principal's name for the SSO authentication.
>
> Users should not be required to set their userID and password for a
> given remote site themselves, we want to hide all of this from them.
> Nor can they modify the URL we want to send them to but as I said, the
> URL will vary by customer (which is an LDAP/jetspeed group
> incidentally).
>
> Obviously I would have to extend one or more of the SSO portlets to do this.
>
> Anyway, I'm just looking for some general advice before I dive too
> deep into this to see if anyone can think of a simpler way to achieve
> something like this.
>
> cheers,
> aaron
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org