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

["George Stanchev" <Gstanchev@xxxxxxxxxx>]

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 <mailto:gstanchev@xxxxxxxxxx> 
 
www.serena.com <http://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.