WS-Fed and WS-Trust support

[Cantor, Scott]

On 7/23/13 12:49 AM, "Peter Williams" <pwilliams at rapattoni.com> wrote:
>
>******* http://wp.me/s1fcz8-16434 is my trivial work

I don't read other source code unless I know it's openly licensed.

> - the PDUs and the "seminar-grade" code I wrote to show I could
>interoperate. It had to be trivial (remember its me, and my skill level)!
>To be fair to the designers and their years of design experience, all I
>did was copy what Microsoft  commercial software already does.

Just because lots of people think they're correctly implementing
delegation doesn't make it correct.

> I spied on the interactions of the firm's lync client (or the Microsoft
>online assistant service, to be more exact) using diagnostic tools the
>firms provides, for that purpose; and then made my web service client do
>the same when pulling some assertions from a couple of STSs in a chain.

Then that's the difference, I'm not going to implement something by
reverse engineering somebody else's proprietary mechanism. Without a
published standard, there is nothing to depend on and no expectation that
it won't change any time they feel like it. That's not anything I care to
support or participate in.

> I think that's a little unfair.

It's entirely fair.

> I've found one and only one (policy) field that is unusual - that
>specified the operational trust policy for an STS-binding - that governs
>the process of responding to the OASIS-defined token issuing service.
>Everything else was pure OASIS standards complying, on the wire and in
>assertion format.

This isn't about syntax, it's about semantics, correct use of standards,
and about publishing a profile that documents the behavior and guarantees
an open change management process.

>Thus, I have to believe that a signed assertion from a bearer channel is
>as viable on the subsequent ws-trust handshake as the (same) assertion
>(content) received from a first active handshake. The nth handshake knows
>NOTHING of previous handshake protocols. Its one bearer token swapped for
>another.., using some or other signaling protocol.

If the original assertion was issued to the STS, it's fine. If not, which
was the *exact* use case you were accusing us of not supporting (a web
site acting on behalf of the user), that's delegation, and it is not
allowed by the SAML standard to forward a short-lived assertion targeted
only at an SP to some other unrelated system. In the sense that in SAML
terms the assertion is not valid for use by that other system.

>*** for what its worth, what I'm seeing is a cascade of bearer tokens,
>with no proof tokens and no secure conversation (protecting the ws-trust
>handshakes). ITs very raw, very basic, and very simple. Even I get it.
>Its also live, commodity, and in "million-site-level production".

Being easy to scale doesn't make it a correct approach. It means there's a
trade-off being made between following standards and applying appropriate
security, and scaling.

>*** thus were one to deliver to my SP over SAML2-P a signed
>SAMl2-conforming assertion with the right claims, non HOKO conformations
>(and the value syntaxes for "attributes" ), I don't see why it should not
>be exchanged by ws-trust for the token that can pass the guard at the
>hosted Exchange API - just like mine do.

If the assertion is appropriately constructed, there is no reason. A
standard SSO profile assertion is not.

-- Scott