Requesting new Assertion to STS
Gina Choi
This is what I try to achieve. The SP already logged the user in and is
requesting a new assertion to STS but corresponding to another Relying Party
in STS. Is this possible with passive AuthnRequest? I read following link and
it is pretty close to what I want to do.
http://lists.oasis-open.org/archives/saml-dev/200605/msg00051.html
The following is AuthnRequest token that I have. Since user is already logged
in, I have NameID value of "gchoi" and user is logged on SP "
https://wkensv0306.global.sdl.corp:8443/Airline/code/Welcome.jsp". I try to
get assertion token corresponding to Relying Party "
https://wkensv0305.global.sdl.corp:8443/Airline/code/Welcome.jsp".
I am working with a guy on the same project, but he is on .NET side and he
seems build everything real quickly using WIF and WCF. On .NET side, they are
getting bootstrap token, but I think that it is a Microsoft term.
I am trying to figure out if I need to improve my AuthnRequest to get
assertion token that I needed.
<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
AssertionConsumerServiceURL="https://wkensv0306.global.sdl.corp:8443/Airline/
code/Welcome.jsp"
ForceAuthn="false"
ID="_f0466908fc171ac4df4a6ac66be3a65bc6e8dbb01b19fadd"
IsPassive="true"
IssueInstant="2012-03-20T18:43:28.829Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">
https://wkensv0305.global.sdl.corp:8443/Airline/code/Welcome.jsp
</samlp:Issuer><samlp:Subject
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">
<samlp:NameID
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">gchoi</samlp:NameID>
</samlp:Subject>
</samlp:AuthnRequest>
Thanks.
Gina Choi
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
Cantor, Scott
>
>This is what I try to achieve. The SP already logged the user in and is
>requesting a new assertion to STS but corresponding to another Relying
>Party
>in STS. Is this possible with passive AuthnRequest? I read following link
>and
>it is pretty close to what I want to do.
>http://lists.oasis-open.org/archives/saml-dev/200605/msg00051.html
IsPassive has nothing to do with it. If you're using SAML protocol, then
you can refer to the SAML profiles and specifications to understand how to
do things. If not, you're not using anything standard and there are no
answers to your questions that don't amount to "make it up as you go
along".
>I am working with a guy on the same project, but he is on .NET side and he
>seems build everything real quickly using WIF and WCF. On .NET side, they
>are
>getting bootstrap token, but I think that it is a Microsoft term.
That's quite easy to do when they make it all up as they go along and
ignore most of the specs, including the ones they wrote.
>I am trying to figure out if I need to improve my AuthnRequest to get
>assertion token that I needed.
You don't need the Subject element in an AuthnRequest, it has nothing much
to do with moving between SPs. The identity of the client is deduced from
the authentication performed to the IdP by the client.
-- Scott
Cantor, Scott
some other list. These aren't really development questions related to our
software.
On 3/22/12 5:23 PM, "Gina Choi" <gc...@sdl.com> wrote:
>
>I looked at SAML V2.0 Holder-of-Key Assertion Profile and SAML V2.0
>Condition
>for Delegation document, but I still can't figure out. Could you specify
>profile name that I need to look at?
I don't know anything about your use case other than I think that you're
hoping for standards where none exist (web services). You started talking
about SAML protocol (AuthnRequests), so I assumed you were perhaps doing
SAML SSO with a browser as a client. If not, the only profile in SAML for
authentication is called ECP. There are no SAML profiles for securing web
services, because that was left to WS-* to define. In other words, if it
doesn't answer your question, SAML's probably not going to.
An STS is a WS-* concept. You can't use SAML messages to communicate with
an "STS" at all, at least in the strict sense of what Microsoft means by
an STS.
> I need to get an assertion token
>corresponding to Relying Party B from Service Provider A and the assertion
>token must contain AttributeStatement.
Well, SPs don't issue tokens, so I don't understand what that means.
And there are no interoperable profiles in SAML for simply cooking up a
request to an IdP for an arbitrary assertion. That isn't how SAML is
designed. You have to profile it into a use case and then define the
message content needed and the semantics the IdP is supposed to follow.
You can't in general take an IdP off the shelf and make it issue a SAML
assertion with no constraints around why it's doing the issuing and what
has to go into the assertion.
>If I do not specify Subject element, how does STS know about which user
>am I
>talking about?
Well, again, there is no STS in SAML and no STS will respond to the
message you asked about.
But IdPs normally identify the subject of the assertion to issue based on
the identity of the party authenticating to them. The only reason for the
Subject element in a request is for advanced cases in which the requester
needs the IdP to represent the subject in a specific manner, but it can't
generally just say "issue a token about Foo" unless Foo can authenticate
itself to the IdP during the delivery of the request. That wouldn't be
secure.
> How do I specify target relying party B in AuthnRequest?
You can't use an AuthnRequest with an STS, but the answer is that by
convention you specify the intended recipient(s) of an assertion using the
Audience element and/or SubjectConfirmation, the latter particularly in
the case of a bearer token. Holder of key tokens don't necessarily need to
be as constrained, but can still be limited by Audience conditions. Bearer
tokens generally will be targeted at particular Recipient URLs at a RP.
But again, you can't just cook up an AuthnRequest and send it to a SAML
IdP and expect magic. You won't get it. SAML's not open ended at runtime
like that. It's flexible in the ability to define new profiles using the
basic messages it supports. It has profile-definition flexibility, not
runtime open-endedness. But profiles require agreement by parties on what
to implement. They take work, planning, and then implementation.