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

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

The references you list are for WS-SecurityPolicy discussions we were having, not WS-Trust.

Not sure is you mean NULL password, empty password or password element missing ? WS-Security does not define the semantics its up to the one validating the message to determine the semantics or follow a profile that has done this already (and I don't know of one). So we could define what we want here and declare when you talk to a Higgins STS these are the rules of engagement.

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 02:16 PM

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

To	"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject	RE: [higgins-dev] Getting a security token on behalf of another party

Hi Anthony,
 
I was looking at a proposal and discussions [1],[2],[3] at WS-SX which I thought 
are corelated with WS-Trust and WS-SecureConversation. May be I was looking
at the wrong place...
 
Let me see if I understand it properly how it will work:
 
In the "unknown secret" case the requesting agent will form an empty-password 
UsernameToken and include it within a <OnBehalfOf> element of RST. It will then
add a supporting token in the message wsse header (in the form of a X509 cert) and
sign it. The STS then, when parsing the RST notices that the 
UsernameToken does not contain enough credentials to fullfill the request. It 
looks for signed supporting token (that matches its security policy) in the request 
header. It then uses that supporting token to extract a DS which matches the username 
described in the <UsernameToken> if the supporting token is valid and the originating
agent is configured on the STS side to act as an OnBehalfOf agent.
 
If I understand it properly, how would the STS distinguish between empty password
and an absent password? Also can the supporting token be the same as the one used 
to sign the message and if so, why include it separately. Can STS just pull it from
the signature or thats in conflict with the standards?
 
Thanks
 
George
 
[1] http://lists.oasis-open.org/archives/ws-sx/200602/doc00001.doc
[2] http://www.oasis-open.org/archives/ws-sx/200602/msg00108.html
[3] http://www.oasis-open.org/archives/ws-sx/200603/msg00052.html

---

From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Friday, January 05, 2007 11:37 AM
To: Higgins (Trust Framework) Project developer discussions
Cc: Higgins (Trust Framework) Project developer discussions; higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] Getting a security token on behalf of another party

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

********************************************************************** 
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