Re: [higgins-dev] Getting a security token on behalf of another party

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

So there has been no talk about having the <OnBehalfOf> support more than 1 token that I'm aware of, we had the issue about requesting multiple tokens and returning multiple tokens which has been addressed (as WS-Trust has completed Public Review and not comments like that have come in). WS-Trust allows for endorsing and supporting tokens, so one of these could be used in place of the "password" or a <Challenge> could be used as a way to provide additional proof.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"George Stanchev" <Gstanchev@xxxxxxxxxx>

"George Stanchev" <Gstanchev@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

01/05/2007 11:33 AM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject	[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
gstanchev@xxxxxxxxxx

www.serena.com 


**********************************************************************
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._______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev