Shibboleth integration with external idp and java ee/.Net application

[Claude Libois]

*"SAML does not depend on cookie sharing, so whatever you're talkingabout
has nothing to do with standards-based Web SSO."*
Well I don't understand how you can achieve SSO between .Net and java then.
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.
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.
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.

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.


To summarize
We would have then
- 2 IDP:

   - - the external one
   - - an internal one(currently implemented by shibboleth) that would do
   the LDAP Authentication.

- 2 SP:

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

There still remains my previous question on how SSO between JAVA and .NET
could be achieved by the IDP/SP ?

Best Regards,
Claude






2017-03-16 17:32 GMT+01:00 Peter Schober <peter.schober at univie.ac.at>:

> * Claude Libois <clibois.work at gmail.com> [2017-03-16 16:58]:
> > Thanks for the explanation. Indeed we wanted to be sure that the IDP
> would
> > keep the session active between java and .Net.
>
> Not sure what that means. The IDP's own session (the one giving the
> subject) has nothing at all to do with the sessions each SAML SP may
> create with the subject.
>
> > I guess this would be done by using a cookie containing the session
> > id and that could be shared between java and .Net application.
>
> SAML does not depend on cookie sharing, so whatever you're talking
> about has nothing to do with standards-based Web SSO.
>
> > We will need indeed several IDP for the same application. One for
> > internal user(agent) and one for external user(Citizen). After some
> > discussion we came to the id of implementing our own proxy idp which
> > would interact with weblogic/ISS and act as sp for the external
> > IDP. Do you know if there are some library that could help managing
> > the SAML V2 lifecycle ? I have already used opensaml in the past but
> > only for saml parsing.
>
> Just because different subjects may use different IDPs does not mean
> you need a proxy. I was merely pointing out that SSO for a single
> subject only works if the IDP used by different SPs is the same. I.e,
> if I had to use IDP A to access SP X and IDP B to access IDP Y there'd
> be no SSO, as SSO in SAML is a function of an (singular) IDP.
> If I can use IDP A to access both SP A and SP B I'd experience SSO
> when accessing the second SP, at the latest.
>
> Maybe my previous comment about "one IDP" only served to confuse, I
> can't tell from the above.
>
> To summarize: If you have several SPs (might be implemented in Java or
> .NET or Python or PHP or whatever -- doesn't matter at all as long as
> you integrate it with some SAML implementation, including the Shib SP)
> you can use that with as many IDPs as needed, no proxies and no
> hierarchies involved!
>
> The most straight forward case then would be using an IDP discovery
> service (several Free/Libre ones available, including the Shib EDS,
> which works anywhere you can host HTML + JS + CSS) and configuing all
> your SPs to use that for session establishment (or put a discovery
> service on each SP, as recommended here,
> https://discovery.refeds.org/).
> The subject then picks the desired IDP herself and continues on to the
> IDP (via the SP, but that's transparent).  All of that is part of the
> SAML spec and works out of the box with Shibboleth. No development, no
> proxies, no cookie sharing.
>
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170316/4c13dbef/attachment-0001.html>