WS-Fed and WS-Trust support

[Peter Williams]

***** The question was how does one do ws-trust'y things with Shib (IDP). Since I'm in the very position of probably having to do that - since a few SAML2 IDPs - do still send us tokens, I thought Id give some context. 

Of course, Shib is just a SAML2 IDP, no different to 15 others - for my purposes.

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

None of this has anything to do with the question that was asked.

*** see above. The question was rather general.

On 7/22/13 1:33 PM, "Peter Williams" <pwilliams at rapattoni.com> wrote:

>academic system are missing what is now commodity in the windows world.
>("Commodity" is defined as I can program it, being a low-skill
>programmer, using only libraries such as dotNet).

No. What you're talking about is a non-trivial act, namely delegation.
Doing it right, let alone securely, is extremely difficult.

******* http://wp.me/s1fcz8-16434 is my trivial work - 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. 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. Eventually my web service client invokes the usual a proof of origin security services on a web service call [request] when getting some email from an Office365 API port. Token accompany the proofs.

**** Of course, my code does not use good coding practice, for a system exposed to a hostile world. Its just the comsec proof. That's all I care about, in my job. Others worry about implementation.

>for example, a Shib SP web app cannot submit a message on the Office 365
>email server (without having to have the users name/password.). In the
>windows  app-building world, active profiles are properly support (and
>relatively easy to implement).

And proprietary and undocumented. That is a false comparison.

****** I think that's a little unfair. 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. That security policy signal  - on an RST - seems to be "extension" since I cannot find where standards folks every agreed that RST messages might express "trust" policy (unlike ports, operations, messages, etc whose functioning is of course easily governed by the security policy rules disclosed in the WSDL bindings).

> One can take the (SAML2 signed assertion) bearer token at that SP and
>use the Office 365's cloud STS (so-called federation gateway) to get a
>token suitable for attaching to the request message by the client agent
>responsible for consuming the "compose API" port offered by the site's
>Office365 subscription.

I don't believe for one minute those assertions are constructed properly
to allow for that.

*** so having implemented 2 of the components (the web service client, and the first STS that exchanges and username token for a SAML assertion), it IS true that the client uses ws-trust as the handshake (not ws-fed passive, or SAML2-P).

*** but I also implemented (trivially) a passive responder - that lands on exchange's web mail, sharepoint, etc. I cannot see one iota of difference between what I mint as assertion on the passive (and interoperable) channel vs the active (and interoperable) channel. 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.

*** 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".

*** 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.

** I suspect** this is what folks are interested in when considering Shib and ws-trust - being able to land on office 365 sites...since that is surely one of the biggest drives of sso adoption now, in academia as elsewhere. Of course, folks want their outlook, voicemail, and lync IM clients to work too. Browser-only sites using that kind of enterprise-offering are PRETTY rare.