Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Getting a security token on behalf of another party

I Higgins usecases are in progress, I know they are somewhere on the site (not sure where, maybe Paul knows). but I can tell you that CardSpace does not support the OnBehalfOf element (yet).

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "George Stanchev" <Gstanchev@xxxxxxxxxx>"George Stanchev" <Gstanchev@xxxxxxxxxx>


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

          01/11/2007 02:09 PM

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

To

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

cc

"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>, <higgins-dev-bounces@xxxxxxxxxxx>

Subject

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

Thanks Anthony,

In case #1, RST request is issued directly agains STS EPR by the client using UsernameToken containing
valid username and password. Full credentials because STS can use the Username and Password from that
token to do authentication. This case is covered by current STS capabilites.

Partial credentials are used when the authentication is performed by the proxy agent and then it "vouches"
for the user with its certificate (as endorising token) which STS is configured to trust. The UsernameToken
in the partial credentials case will contain <Username> element but no <Password> element and thats why
I refer to it as partial - the STS cannot use it to authenticate the requestor. This "vouching" scenario is used
only when the authentication by the proxy agent cannot provide full credentials that can be passed to the
STS (as in an NTLM authentication for example)

So regarding the roadmap, where can I see what are the Higgins STS scenarios? Is it posted somewhere?
Sorry if I have overlooked it...

Thanks

George Stanchev




From: higgins-dev-bounces@xxxxxxxxxxx on behalf of Anthony Nadalin
Sent: Thu 1/11/2007 12:07 PM
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 to clarify:

#1 RST is sent to proxy agent ? What do you mean by full credentials ?

So assumption is that we will provide a full function STS based upon the OASIS WS-Trust Standard (which will is going trough final paperwork now) but we are concentrating on Higgins scenarios first and getting that function done.

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/10/2007 03:24 PM

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

"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>, "Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc

"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>, <higgins-dev-bounces@xxxxxxxxxxx>
Subject

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

Thanks Anthony,

I have overlooked that the password element in UsernameToken is optional.

So I think we have our use-cases covered. Let me enumerate them below for completeness:

1. Normal RST request: wsse header contains UsernameToken with full credentials for authentication.
2. RST request from a proxy agent with originator's credentials: RST contains OnBehalfOf element which
contains a full UsernameToken. The proxy agent endorses the call by signing the message with
its certificate and including it in the signature. (real life scenario: the agent serves a logon page in which
the user enters username/password for a SSO)
3. proxy agent performs authN of the originator and requests a token on its behalf without full credentials:
RST contains OnBehalfOf element which contains UsernameToken with absent Password element.
The proxy agent endorses the call by signing the message with its cert and including it in the signature
(real life scenario: the agent performs NTLM authentication which results in principal but no secret that
can be used for passing to STS)
4. RST "Renew" request from proxy agent, previously issued security token as user credentials: wsse header
contains previously issued, valid and unexpired SAML token. Proxy agent endorses the call by
signing the message and including its certificate in the signature. (real life scenario: in ALF, there is
a component which uses longer-lived security tokens. It needs to convert shorter-lived security tokens
into longer ones

As far as I know, only 1 is supported by higgins right now. Realistically, how far into the future cases 2,3 and 4
will be supported?

Thanks!

Regards,
George Stanchev

From: higgins-dev-bounces@xxxxxxxxxxx on behalf of Anthony Nadalin
Sent: Mon 1/8/2007 7:48 PM
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

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

GIF image

GIF image

GIF image

GIF image

GIF image

GIF image

GIF image

Back to the top