|
Home > Archive > WebSphere Application Server > May 2004 > Custom authentication with LTPA / SSO
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Custom authentication with LTPA / SSO
|
|
| Darren Davison 2004-05-24, 7:30 am |
| Hi,
We have SSO configured between a cluster of WAS 5.x servers and a
cluster of Domino 6.0.x servers via LTPA. This works fine in terms of
standard J2EE security but I have a problem as follows.
If I authenticate against the Domino servers first and then visit a
Websphere generated page that is NOT part of a security constraint,
then WAS never attempts to decrypt the LTPA token sent by the browser,
and request.getUserPrincipal() returns null. Requesting a SECURE page
causes this to happen and WAS then recognizes the principal without
needing to prompt for authentication - exactly as expected for SSO.
Unfortunately, I need to know who the user is even on 'non-secured'
pages since the application does different things depending on whether
the user has authenticated or not. In other words, I cannot FORCE
authentication for this page by securing it in web.xml.
Is there a way, say in a Filter, to force WAS to determine user
credentials from an LTPA cookie - even if the page is not secured?
Effectively doing the same as a post to the j_security_check servlet
in the 'background'?
Many thanks,
Darren.
| |
| Ken Yee 2004-05-24, 11:30 pm |
| darren@davison.uk.net (Darren Davison) wrote in
news:35d7e0ab.0405240126.4211b5bd@posting.google.com:
> Unfortunately, I need to know who the user is even on 'non-secured'
> pages since the application does different things depending on whether
AFAIK, this is the way most J2EE servers do this, even
JBoss.
When I wrote my JBoss/Domino SSO plugin, the first thing I
did was fix this so that the roles and username are available
on unsecured pages as well. Pretty annoying if it doesn't do
this if you come from a Domino background ;-)
ken
| |
| Darren Davison 2004-05-25, 7:31 am |
| Ken Yee <ND6@excite.com> wrote
> AFAIK, this is the way most J2EE servers do this, even
> JBoss.
yes, I know. What I don't know - and what I was really asking - is
whether there is a WebSphere specific API that I can use to decrypt
the LTPA token and obtain the Principal. Something like..
Principal p = LtpaAuthenticationClass.decryptLtpaValue(ltpaCookieValue);
- or -
LtpaAuthenticationClass.authenticate(request);
Principal p = request.getUserPrincipal();
... which I could use within a Filter object if the LTPA token is found
and no corresponding Principal is available. There must be something
along these lines in WAS' implementation of the standard J2EE
authentication model, the question is whether it is available to
client code.
Many thanks,
Darren.
| |
| Ken Yee 2004-05-25, 4:30 pm |
| darren@davison.uk.net (Darren Davison) wrote in
news:35d7e0ab.0405250021.7180466b@posting.google.com:
> whether there is a WebSphere specific API that I can use to decrypt
> the LTPA token and obtain the Principal. Something like..
AFAIK, there is nothing documented. :-(
ken
| |
| Paul Ilechko 2004-05-26, 11:30 pm |
| Darren Davison wrote:
> Hi,
>
> We have SSO configured between a cluster of WAS 5.x servers and a
> cluster of Domino 6.0.x servers via LTPA. This works fine in terms of
> standard J2EE security but I have a problem as follows.
>
> If I authenticate against the Domino servers first and then visit a
> Websphere generated page that is NOT part of a security constraint,
> then WAS never attempts to decrypt the LTPA token sent by the browser,
> and request.getUserPrincipal() returns null. Requesting a SECURE page
> causes this to happen and WAS then recognizes the principal without
> needing to prompt for authentication - exactly as expected for SSO.
>
> Unfortunately, I need to know who the user is even on 'non-secured'
> pages since the application does different things depending on whether
> the user has authenticated or not. In other words, I cannot FORCE
> authentication for this page by securing it in web.xml.
If the application does different things depending on whether the user
has authenticated, the page is *not* "non-secured". I suggest you
re-think your design.
| |
| Ken Yee 2004-05-26, 11:30 pm |
| Paul Ilechko <plechik@us.ibm.com> wrote in news:c9373v$74be$2
@news.boulder.ibm.com:
> If the application does different things depending on whether the user
> has authenticated, the page is *not* "non-secured". I suggest you
> re-think your design.
Actually, for folks used to doing things in Domino where roles
apply to an entire application (we can also make roles apply at the
document or record level, for you RDBMS folks, to further restrict
security :-), we use the roles to display parts of the UI depending
on what roles they have.
E.g., you go to the main page of a web site and you're an Admin.
You want to display an admin link to take you to an admin section.
Works great in Domino (and in JBoss w/ my SSO plugin ;-), but
doesn't in WAS unless you make the entire home page of the site
protected via declarative security. But everyone uses that as
the home page, so you don't want to use declarative security.
ken
| |
| Darren Davison 2004-05-27, 4:34 pm |
| Paul Ilechko <plechik@us.ibm.com> wrote in message news:<c9373v$74be$2@news.boulder.ibm.com>...
> If the application does different things depending on whether the user
> has authenticated, the page is *not* "non-secured". I suggest you
> re-think your design.
There's nothing wrong with the design. Standard J2EE security is a
very blunt instrument and that's why the majority of non-trivial J2EE
apps implement custom security frameworks. I would too if I didn't
need the SSO with Domino. This in itself is not a WAS issue, it needs
to be addressed in the specs.
My home page (in the WebSphere application) should be accessible to
all, whether they have authenticated or not. However it has the
capability to show personalised content if the user HAS authenticated.
It also shows the logged in status of the user - there's nothing
wrong with either of those use cases.
Now, if my users login to a Domino application in the same domain
FIRST and then visit the WebSphere app home page, the status will show
that they are NOT logged in and none of their personal information
will be available.
The fix is semantically trivial - the WebSphere server simply needs to
expose an API that allows custom code to pass an LTPA string to a
method and receive a javax.security.Principal object in return. This
is what it does internally anyway in order to authenticate against a
page within a security constraint.
If WAS doesn't expose such an API (and responses so far would seem to
indicate that that is the case) then the design fault is in WAS I'm
afraid, not my application. Other application servers DO expose the
equivalent API's for various authentication mechanisms.
Darren.
| |
| Paul Ilechko 2004-05-27, 4:34 pm |
| Darren Davison wrote:
> Paul Ilechko <plechik@us.ibm.com> wrote in message news:<c9373v$74be$2@news.boulder.ibm.com>...
>
>
>
>
> There's nothing wrong with the design. Standard J2EE security is a
> very blunt instrument and that's why the majority of non-trivial J2EE
> apps implement custom security frameworks. I would too if I didn't
> need the SSO with Domino. This in itself is not a WAS issue, it needs
> to be addressed in the specs.
>
> My home page (in the WebSphere application) should be accessible to
> all, whether they have authenticated or not. However it has the
> capability to show personalised content if the user HAS authenticated.
> It also shows the logged in status of the user - there's nothing
> wrong with either of those use cases.
>
> Now, if my users login to a Domino application in the same domain
> FIRST and then visit the WebSphere app home page, the status will show
> that they are NOT logged in and none of their personal information
> will be available.
>
> The fix is semantically trivial - the WebSphere server simply needs to
> expose an API that allows custom code to pass an LTPA string to a
> method and receive a javax.security.Principal object in return. This
> is what it does internally anyway in order to authenticate against a
> page within a security constraint.
>
> If WAS doesn't expose such an API (and responses so far would seem to
> indicate that that is the case) then the design fault is in WAS I'm
> afraid, not my application. Other application servers DO expose the
> equivalent API's for various authentication mechanisms.
That's all well and good, but it doesn't solve your problem. You can ask
IBM to consider changing, but it won't happen quickly, and meanwhile you
still need a solution. I don't see why you can't have a simple home page
for everyone, with a link to get personalized info that would go to a
protected page. Provided domino had aready created an LTPA cookie you
should automatically signon to WAS at that point.
| |
| Darren Davison 2004-05-29, 11:35 pm |
| Paul Ilechko <plechik@us.ibm.com> wrote in message news:<c94t0a$993m$1@news.boulder.ibm.com>...
> still need a solution. I don't see why you can't have a simple home page
> for everyone, with a link to get personalized info that would go to a
> protected page.
simply because that's not how the users want it to operate. This is
actually a very common scenario - portal type websites show you a home
page with your prefered content if it knows who you are, or a default
page if not.
I do in fact have a solution of sorts in place that makes it work, but
it's basically a horrible kludge involving sending re-directs from a
servlet filter. My feeling is that WAS should expose the API it
already uses to make the solution significantly more elegant.
Think I'll talk to our rep about a possible PMR for this. I'll let
you know how it goes.
Regards,
Darren.
|
|
|
|
|