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

Peter Schober peter.schober at univie.ac.at
Thu Mar 16 16:37:30 EDT 2017


* Claude Libois <clibois.work at gmail.com> [2017-03-16 21:14]:
> *"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.

I can only repeat mysef here:

* Peter Schober <peter.schober at univie.ac.at> [2017-03-16 14:44]:
> SSO in SAML is a function of the HTTP user agent establishing a
> session with the IDP.

There is not SSO "between" applications. Each SAML SP (protecting an
application or more) sends SAML protocol messages to an IDP and the
IDP replies to the SP, via specified methods. If an SP sends an HTTP
User Agent to an IDP the subject has accessed before (and still has a
valid SSO session with), the subject will experience "SSO". Otherwise
the subject will need to authenticate again (typically by entering
username and password) at the IDP before being returned to the SP.

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

Yes.

> Now we try to reach a .Net application with it's own sp implementation. How
> can we avoid a re-authentication ?

The SAML SP protecting the .NET application does exactly the same
thing as the SAML SP for the Java does. And if the subject's browser
has an active SSO session at that IDP, they will be returned to the
.NET resource right away, without having to enter credentials.
That's SSO using SAML. It's all in the specification and technical
overview and the Shibboleth CONCEPT material in the Shib wiki (and
wikipedia and ...)

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

Yes.

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

Yes, but what the IDP does to recognize the subject is not specified
by SAML). Likely create a session (e.g. in memory or a data store) and
reference that session in an HTTP Cookie sent to the subject. The IDP
has a session with the subject's browser like any other web app on the
planet. That's how it can issue asertions for newly accessed SPs
without asking for authentication each time.

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

The Shibboleth EDS is meant to be used with the Shibboleth SP, but if
you can produce JSON in a specific format then that's all it needs.
There are also other implementations around, but those usually either
need to run code server-side (e.g. SWITCHwayf) or depend on external
services (e.g. DiscoJuice).

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

JFYI, the Shibboleth SP will work for both Java and .NET (as well as
anything else you can put Apache httpd or MS IIS in front, or supports
most of fastcgi). For Java you'd usually tunnel from Apache httpd to
the Java servet container via AJP (i.e., only httpd is accessible from
the outside and terminates TLS and does all the SAML using the Shib
SP). For .NET you'd use MS-IIS and the Shib SP module for that.

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

If my explanations above are not sufficient please do have a look at
the fine documentation, e.g.:
https://wiki.shibboleth.net/confluence/display/CONCEPT/
Especially:
https://wiki.shibboleth.net/confluence/display/CONCEPT/FlowsAndConfig
https://wiki.shibboleth.net/confluence/display/CONCEPT/Sessions
-peter


More information about the users mailing list