<div dir="ltr"><i><span style="font-size:12.8px">"SAML does not depend on cookie sharing, so whatever you're talking</span><br style="font-size:12.8px"><span style="font-size:12.8px">about has nothing to do with standards-based Web SSO."</span></i><div><span style="font-size:12.8px">Well I don't understand how you can achieve SSO between .Net and java then. </span></div><div><span style="font-size:12.8px">Imagine we got a SP on both Java and .Net. I then try to access to a java application but the sp will detect that the user is not yet authenticated.</span></div><div><span style="font-size:12.8px">It will redirect to the idp and the user will do the authentication process(username/password, certificate,...). A the end of the process, the idp will redirect to the sp with the right information(either with http post binding or saml artifact binding). The sp will then create what's needed for java(UserPrincipal) to assert that the user is authenticated.</span></div><div><div>Now we try to reach a .Net application with it's own sp implementation. How can we avoid a re-authentication ? I make the assumption that the .Net sp as not shared data with the java one. So basicaly it will redirect once again to the idp. How is it possible that the idp detects that the user has already been indentified on it's own system ? My guess was that a cookie was set on the idp domain with the session id.</div></div><div><br></div><div>We are using weblogic as jee application server which comes with a builtin SP. You're right about teh idp discovery service. That's what we want. We were thinking about implementing our own with kind of spring security application but if it already exist then that's fine. I guess we could indeed configure an IDP Discovery service that would be shibboleth EDS. Things are getting a bit more clear for me now on how to set up things.</div><div><br></div><div><br></div><div>To summarize</div><div>We would have then</div><div>- 2 IDP:</div><div><ul><li>- the external one<br></li><li>- an internal one(currently implemented by shibboleth) that would do the LDAP Authentication.<br></li></ul></div><div>- 2 SP:</div><div><ul><li>- the one built-in with weblogic. Moreover this sp would create our UserPrincipal(we can map saml attributes to parameter). Still have to check if we can trigger a custome LoginModule tought.<br></li><li>- the one that will be on the .Net part. I don't know this part but some say that IIS doesn't support SAML2 and that we should use kind of ADFS in front of...<br></li></ul></div><div>There still remains my previous question on how SSO between JAVA and .NET could be achieved by the IDP/SP ?</div><div><br></div><div>Best Regards,<br>Claude</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-16 17:32 GMT+01:00 Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Claude Libois <<a href="mailto:clibois.work@gmail.com">clibois.work@gmail.com</a>> [2017-03-16 16:58]:<br>
<span class="">> Thanks for the explanation. Indeed we wanted to be sure that the IDP would<br>
> keep the session active between java and .Net.<br>
<br>
</span>Not sure what that means. The IDP's own session (the one giving the<br>
subject) has nothing at all to do with the sessions each SAML SP may<br>
create with the subject.<br>
<span class=""><br>
> I guess this would be done by using a cookie containing the session<br>
> id and that could be shared between java and .Net application.<br>
<br>
</span>SAML does not depend on cookie sharing, so whatever you're talking<br>
about has nothing to do with standards-based Web SSO.<br>
<span class=""><br>
> We will need indeed several IDP for the same application. One for<br>
> internal user(agent) and one for external user(Citizen). After some<br>
> discussion we came to the id of implementing our own proxy idp which<br>
> would interact with weblogic/ISS and act as sp for the external<br>
> IDP. Do you know if there are some library that could help managing<br>
> the SAML V2 lifecycle ? I have already used opensaml in the past but<br>
> only for saml parsing.<br>
<br>
</span>Just because different subjects may use different IDPs does not mean<br>
you need a proxy. I was merely pointing out that SSO for a single<br>
subject only works if the IDP used by different SPs is the same. I.e,<br>
if I had to use IDP A to access SP X and IDP B to access IDP Y there'd<br>
be no SSO, as SSO in SAML is a function of an (singular) IDP.<br>
If I can use IDP A to access both SP A and SP B I'd experience SSO<br>
when accessing the second SP, at the latest.<br>
<br>
Maybe my previous comment about "one IDP" only served to confuse, I<br>
can't tell from the above.<br>
<br>
To summarize: If you have several SPs (might be implemented in Java or<br>
.NET or Python or PHP or whatever -- doesn't matter at all as long as<br>
you integrate it with some SAML implementation, including the Shib SP)<br>
you can use that with as many IDPs as needed, no proxies and no<br>
hierarchies involved!<br>
<br>
The most straight forward case then would be using an IDP discovery<br>
service (several Free/Libre ones available, including the Shib EDS,<br>
which works anywhere you can host HTML + JS + CSS) and configuing all<br>
your SPs to use that for session establishment (or put a discovery<br>
service on each SP, as recommended here,<br>
<a href="https://discovery.refeds.org/" rel="noreferrer" target="_blank">https://discovery.refeds.org/</a>)<wbr>.<br>
The subject then picks the desired IDP herself and continues on to the<br>
IDP (via the SP, but that's transparent).  All of that is part of the<br>
SAML spec and works out of the box with Shibboleth. No development, no<br>
proxies, no cookie sharing.<br>
<div class="HOEnZb"><div class="h5"><br>
-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>