WS-Fed and WS-Trust support

[Peter Williams]

________________________________________
From: Peter Williams
Sent: Tuesday, July 23, 2013 11:07 AM
To: Shib Dev
Subject: RE: WS-Fed and WS-Trust support

Its highly inappropriate to impugn reputations ("its proprietary") when folks have made every effort to develop and use open standards - so anyone can participate. Its clear that this stuff doesn't require specialists any more, being ever more mainstream. As I keep saying, if I can do, so can a million vb programmers, some 1000 of which will no doubt do an excellent security implementation job. This moment is a bit like PKI in 2000, when we got the "cert" dumbed down so a million sites can all run their own CA servers, rather than be held captive by the likes centralized providers like VeriSign/SAIC, GTE (NSA affiliates).

anyways, all folks - not just consultant types - can read a not- too technical discussion of Shib and Microsoft cooperation from the excellent CRNS doc, at 
http://www.microsoft.com/en-us/download/confirmation.aspx?id=35464 

There we see a nice writeup up Shib 2 working with Office 365. It includes showing how the Shib assertion obtained over an ECH/PAOS handshake is used much as ws-trust is used for my own sts. Likewise, the token thus is further translated by another Microsoft-STS (using an ws-trust handshake) into the form required for use at API at ports such as activeSync (for your native phone app) or similar. Of course, activeSyync client may also be hosted in a "website-device", with a browser acting as a glorified terminal accessing that (remote) UA function.

Now, Whether Shib likes it or not, I don't see why there cannot be further translations (of bearer tokens). My own STS (call it #b) produces tokens consumed by Office STS (call it #c) that are presented to API providers to pass guards. Typically, #b takes a username token, but nothing so requires that. For all it matters, it can consume a bearer token from a websso handshake - instread. Little has changed in the handoff-of-bearer-token model.

Now we have Shib and ws-trust working even better together - and doing something REALLY useful (rather than project some journal publishers governance rules).

Does any of THAT require software to be added to Shib? (to make SHib WS-trust "cooperative"? No. Of course, Shib IDP's ECP is just a STS with PAOS bindings.

So Im happy. Nothing Im doing is "proprietary". All I've done is so what a couple of other vendors have done (emulating ADFS), or what Shib has done in cooperating with a couple of token translation gateways (Azure AD, and Microsoft Federation Gateway).

Would not be in the least surprised to learn that several folks here have private Microsoft consultancy arrangements on the topics discussed, above, to make it work, and get THAT excellent level of Shib setup detail all sorted.



________________________________________
From: dev-bounces at shibboleth.net [dev-bounces at shibboleth.net] on behalf of Cantor, Scott [cantor.2 at osu.edu]
Sent: Tuesday, July 23, 2013 8:36 AM
To: Shib Dev
Subject: Re: WS-Fed and WS-Trust support

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


--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net