| [higgins-dev] Getting a security token on behalf of another party |
|
Hello,
I am working on the
Eclipse ALF project. We are planning to adopt and use
the Higgins STS as
backbone for a SSO functionality for ALF-enabled applications.
However, we have couple of use cases which I am not sure on how
to address
which I needed some help
with.
There are several
occasions where a party different than the subject being
authenticated needs
to request a token on behalf of that
subject. For example
we will have a logon
application which supports WS-Federation Passive Requestor
Profile and which serves
a login page for the user credentials which are then
packaged in a RST call to
the STS. I know this use case is supported currently.
However, we are planning to also provide NTLM authentication via
the SAMBA jcifs
filter in supported app servers. The jcifs filter handles the
authentication and
then passes forward the filter chain java.security.Principle containing the
username but no additional supporting authentication secrets (such
as
password or certs). The way we see this being handled is that we
need have a trust
relationship b/w the
logon agent and the STS (properly configured public
key probably?). In
the NTLM authN case, we can build a RST with
a <OnBehalfOf>
element in which we will
inclde an <UsernameToken> and
an X509 token
as supporting token. The
<UsernameToken> will contain username only and
an empty password. The
STS then will extract the primary and supporting tokens, check
if they are trusted and
if they originate from agents authorized to act on
behalf of other users and
honor the request. How is this honoring going to
be acomplished since
there are impartial credentials present (username with
no password)? Does that
gravitate towards the recent discussion on this list
regarding the self-signed
card and how its claims are going to be extracted
from the CP? Also there
seem to has been some recent discussions/changes
to the <OnBehalfOf>
schema at the OASIS site. In WS-Trust 1.0 it states that
it allows a *single* sec
token, sec token reference or wsa:EndpointReference
as element. There has
been discussion about ammending the spec to allow
multiple tokens to be
included in <OnBehalfOf> element of RST which is needed
in our case.
The second use case is
similiar to the one described above, however the
requesting agent will
supply a valid (STS-issued SAML) token as primary
user credential and will
request a longer-lived token. Basically a renew
with supplying endorsing
credentials (its public key/X509 cert) to make sure
the request is honored.
Thanks in
advance.
George
Stanchev
George
Stanchev
Sr. Software Developer
Serena Software,
Inc
(801)
299-9634
 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. |