WS-Fed and WS-Trust support

[Peter Williams]

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

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

We have very few links that talk SAML2 IDPs (and Shib IDP specifically). I'm thinking of imposing the policy that all new agreements with Shib IDPs are required to use the signed-assertion variant of the passive sp-initiated flow, rather than signed-POST. This would allow our SP to at least add the kind of value described above.


________________________________________
From: dev-bounces at shibboleth.net [dev-bounces at shibboleth.net] on behalf of Peter Schober [peter.schober at univie.ac.at]
Sent: Monday, July 22, 2013 12:43 AM
To: dev at shibboleth.net
Subject: Re: WS-Fed and WS-Trust support

* adam_j_bradley <adam_j_bradley at yahoo.com> [2013-07-22 04:42]:
> I'm currently investigating the feasibility of adding WS-Fed and
> WS-Trust support to Shibboleth and was wondering if there is any
> guidance, or guide on how to write custom add-ins.

To what Shibboleth software, specifically?
The Shibboleth SP has support for WS-Fed in the "passive" role,
cf. https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPADFS
so you'd need to be more specific.
-peter
--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net