<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><u>Accuracy</u> :<br>
The two IDP are using the same LDAP and retrieve the same
attributes (attribute-resolver.xml).<br>
We have these two to migrate applications (with SP) from IDP v2 to
v3.<br>
<br>
I will continue to investigate.<br>
<br>
<br>
On 17/09/2015 09:35, Peter Schober wrote:<br>
</div>
<blockquote cite="mid:20150917073517.GC25174@aco.net" type="cite">
<pre wrap="">* <a class="moz-txt-link-abbreviated" href="mailto:romain.dauby@orange.com">romain.dauby@orange.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:romain.dauby@orange.com"><romain.dauby@orange.com></a> [2015-09-17 09:15]:
</pre>
<blockquote type="cite">
<pre wrap="">Actually we have 2 identity providers in the company, we would like to build
a federation.
Each SP has it's own IDP and only one. The goal is if a user connect to a SP
with IDP1, he should not need to authenticate if he wants access to another
SP linked to IDP2. Using a WAYF is not needed.
</pre>
</blockquote>
<pre wrap="">
You still need discovery: Either an SP is "linked" (your term) to an
IDP, meaning it will send all requests (if auth is needed) to one
specific, hardcoded IDP -- in which case subjects from the other IDP
cannot log in to that SP in the normal way -- or you'll have to ask
the subject what IDP to use, on every SP, every time.
Each SP has its own session, so having authenticated to one SP (from
either IDP) will not magically create a session at the other SP.
You'll always have to select a "log in" link and pick your IDP.
SSO only applies to what happens after that: No explicit need to
authenticate at a given IDP if you have already used that IDP and the
session with that IDP is still alive.
</pre>
<blockquote type="cite">
<pre wrap="">IDP1 is v2.1.5
</pre>
</blockquote>
<pre wrap="">
That's 5 years old and ticks all the boxes on possible/available
vulnerabilities, see
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/SecurityAdvisories">https://wiki.shibboleth.net/confluence/display/SHIB2/SecurityAdvisories</a>
</pre>
<blockquote type="cite">
<pre wrap="">Im looking for for a tutorial / guideline / how-to build a federation.
The wiki shibboleth with this article isn't helping me as much as Im noob :
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/BuildAFederation">https://wiki.shibboleth.net/confluence/display/SHIB2/BuildAFederation</a>
</pre>
</blockquote>
<pre wrap="">
Sure, we're just gonna write another long piece explaining everything
again, based on that alone. (Hint: Ask specific questions what is unclear.)
For 2 SPs and 2 IDPs just make sure every SP has SAML Metadata
available for both IDPs, and every IDP has SAML Metadata available for
both SPs. Then add the Shibboleth EDS to both SPs (or deploy one
"centrally" or use another SAMLDS implemetation) and you're done.
-peter
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<div>
<img src="cid:part1.09030701.04050208@orange.com" height="40"
width="94">
<p style="font-family: Arial, sans-serif; margin-top: 0pt;
margin-bottom: 0pt; font-size: 10pt; color:#000000;">
<br>
<b>Romain DAUBY</b>
<br>
Ingénieur d'Etudes SI
<br>
<b style="color:#f60">Orange Applications for Business</b>
<br>
SCE / OAB / DPO / DSPM / SIE
<br>
<br>
Bureau : +33 (0)5 57 57 99 64
<br>
<a href="mailto:romain.dauby@orange.com">romain.dauby@orange.com</a>
<br>
<br>
Immeuble le Concorde
<br>
22-26 quai de Bacalan
<br>
33300 BORDEAUX
<br>
<a href="http://www.orange-business.com/fr">www.orange-business.com/fr</a>
</p>
</div>
</div>
<PRE>_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
</PRE></body>
</html>