Requesting new Assertion to STS

[Cantor, Scott]

Please direct further questions on this topic to saml-dev at OASIS, or
some other list. These aren't really development questions related to our
software.

On 3/22/12 5:23 PM, "Gina Choi" <gchoi at 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.

-- Scott