<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="generator" content="Windows Mail 17.5.9600.20413">
<style type="text/css"><!--html { font-family: "Color Emoji", "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; }--></style><style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst,
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle,
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style>
</head>
<body dir="ltr">
<div data-externalstyle="false" dir="ltr" style="font-family: 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif';font-size:12pt;">
<div>subscribe to windows azure, and get a websso protocol relay (called Azure AD).</div>
<div><br>
</div>
<div>your partners RP sends request to the relay, indicating that shib IDP is the home realm. THe gateway will, ahem, gateway.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>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.</div>
<div>There are microsoft papers around showing how to do all the Shib IDP config, but a visit to the dentist might be less painful.<br>
</div>
<div data-signatureblock="true"><br>
</div>
<div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Segoe UI", "Meiryo", "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;"><b>From:</b> <a href="mailto:giantjamsandwich@gmail.com" target="_parent">Brian
Reindel</a><br>
<b>Sent:</b> ‎Friday‎, ‎March‎ ‎28‎, ‎2014 ‎11‎:‎05‎ ‎AM<br>
<b>To:</b> <a href="mailto:dev@shibboleth.net" target="_parent">Shib Dev</a></font></div>
</div>
<div><br>
</div>
<div dir="">
<div id="readingPaneBodyContent">Thanks Scott, this is definitely why I wanted to ask because I don't<br>
appear to be thinking about it right. So I guess I will focus in on<br>
this:<br>
<br>
>> ADFS supports SAML 2.0, so the best choice is to use that.<br>
<br>
Are you saying the client would use ADFS to connect to our Shibboleth<br>
IdP using SAML 2 assertions?<br>
<br>
<br>
On Fri, Mar 28, 2014 at 10:37 AM, Cantor, Scott <cantor.2@osu.edu> wrote:<br>
> On 3/28/14, 10:27 AM, "Brian Reindel" <giantjamsandwich@gmail.com> wrote:<br>
><br>
>>We have an existing enterprise SSO solution using Shibboleth (one IdP<br>
>>and several SPs). We have a new client, and they use ADFS in house.<br>
>>They want to authenticate into our product using WS-Federation, but<br>
>>I'm having trouble understanding the relationship of the various<br>
>>technologies involved.<br>
><br>
> Are you the IdP or the SP? I'm not following, you seem to be saying both.<br>
> Shibboleth as an IdP does not support WS-federation any more. The SP does,<br>
> though it's very little used.<br>
><br>
> ADFS supports SAML 2.0, so the best choice is to use that.<br>
><br>
>>As I understand it in Shibboleth terms at a high level, they have an<br>
>>SP that we would trust as a relying party through the appropriate IdP<br>
>>configuration as usual. They would authenticate, and upon return to<br>
>>their system they would simply redirect over to our SP (product) that<br>
>>would then communicate with the IdP and establish trust based upon the<br>
>>previous authentication. Does that sound correct at a very high level?<br>
>>We currently have two login handlers configured (RemoteUser and<br>
>>ExternalAuthn), and I'm also curious how those handlers fit into the<br>
>>picture.<br>
><br>
> You've lost me there, you seem to be mixing flows up in odd ways, so<br>
> you'll have to be much clearer about what your goal is and how you expect<br>
> to connect things.<br>
><br>
>>I really want to know what is the appropriate flow in the given<br>
>>scenario. Other than some additional configuration caveats for our IdP<br>
>>to support WS-Federation I don't see any glaring holes.<br>
><br>
> There is no such configuration.<br>
><br>
>>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPADFS<br>
><br>
> That's about the Shibboleth SP.<br>
><br>
>><br>
>>http://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx<br>
><br>
> And that's about using SAML, not WS-Fed.<br>
><br>
> This is really a users list question insofar as you're not writing code<br>
> (unless you want to extend the IdP to do WS-Fed).<br>
><br>
> -- Scott<br>
><br>
><br>
> --<br>
> To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net<br>
--<br>
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net<br>
</div>
</div>
</div>
</body>
</html>