WS-Federation resource provider relationship with our IdP

[Peter Williams]

subscribe to windows azure, and get a websso protocol relay (called Azure AD).

your partners RP sends request to the relay, indicating that shib IDP is the home realm. THe gateway will, ahem, gateway.

Formally, the semantics of your Shib SP and the partner RP are different. One is receiving SAML2 sessions. The other is borrowing the Shib IDP as an authentication authority, only.

One provisions users in the gatewayv so names from Shib IDP pick up attributes. One side benefit is that oauth and openid connect comes fro free, then

You are unlikely to get much support, here on or on users list, on how to make Shib IDP best work with the scenario, since as authentication authority its also has to act as a mini authorization/attribute authority and supply in the authorization statement some id fields.
There are microsoft papers around showing how to do all the Shib IDP config, but a visit to the dentist might be less painful.

From: Brian Reindel<mailto:giantjamsandwich at gmail.com>
Sent: ?Friday?, ?March? ?28?, ?2014 ?11?:?05? ?AM
To: Shib Dev<mailto:dev at shibboleth.net>

Thanks Scott, this is definitely why I wanted to ask because I don't
appear to be thinking about it right. So I guess I will focus in on
this:

>> ADFS supports SAML 2.0, so the best choice is to use that.

Are you saying the client would use ADFS to connect to our Shibboleth
IdP using SAML 2 assertions?


On Fri, Mar 28, 2014 at 10:37 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 3/28/14, 10:27 AM, "Brian Reindel" <giantjamsandwich at gmail.com> wrote:
>
>>We have an existing enterprise SSO solution using Shibboleth (one IdP
>>and several SPs). We have a new client, and they use ADFS in house.
>>They want to authenticate into our product using WS-Federation, but
>>I'm having trouble understanding the relationship of the various
>>technologies involved.
>
> Are you the IdP or the SP? I'm not following, you seem to be saying both.
> Shibboleth as an IdP does not support WS-federation any more. The SP does,
> though it's very little used.
>
> ADFS supports SAML 2.0, so the best choice is to use that.
>
>>As I understand it in Shibboleth terms at a high level, they have an
>>SP that we would trust as a relying party through the appropriate IdP
>>configuration as usual. They would authenticate, and upon return to
>>their system they would simply redirect over to our SP (product) that
>>would then communicate with the IdP and establish trust based upon the
>>previous authentication. Does that sound correct at a very high level?
>>We currently have two login handlers configured (RemoteUser and
>>ExternalAuthn), and I'm also curious how those handlers fit into the
>>picture.
>
> You've lost me there, you seem to be mixing flows up in odd ways, so
> you'll have to be much clearer about what your goal is and how you expect
> to connect things.
>
>>I really want to know what is the appropriate flow in the given
>>scenario. Other than some additional configuration caveats for our IdP
>>to support WS-Federation I don't see any glaring holes.
>
> There is no such configuration.
>
>>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPADFS
>
> That's about the Shibboleth SP.
>
>>
>>http://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx
>
> And that's about using SAML, not WS-Fed.
>
> This is really a users list question insofar as you're not writing code
> (unless you want to extend the IdP to do WS-Fed).
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140328/f5847d97/attachment.html