Implementation of SSO solution in intranet with proxy using SAML

[Oliver Wulff <oliver.wulff@zurich.ch>]

<img
src="http://zdownload.zurich.com/mailimages/ZHP_MailHeader.gif"; />

Hi there

I've seen the following usecase recently which has been implemented with
SAML 1.1.

It's a company internal Web SSO solution (Intranet). All web applications
(Java, .NET) are proxied by a reverse proxy which does the authentication
once when the user access a web application the first time. If the user
accesses other web applications the security context/session is re-used by
the proxy without challenging the user for the credentials. The URL syntax
looks like this:
http://www.mycompany.com/<application name>

The proxy challenges the user initially for authentication before he
forwards the request to the target web application. The browser has never
access to the target web application container directly. The target web
application provides an ACS to create a secure session in the app server.
The proxy acts as the IdP and has implemented an ITS (Source site first).

I'm wondering whether SAML is diverted from its indended use by the use
case described above.

The SAML 1.1 technical overview describes in section 2 the scenario
"Government Portal" which seem to match with the above case.
http://xml.coverpages.org/SAML-TechOverviewDraft11.pdf

The technical overview of SAML 2.0 doesn't mention such kind of scenario in
http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

I've got the following question for you.

1) The usecases described in the technical overview for web sso show a
browser which goes first to the SP or IdP and accesses then the other site.
Redirects are used to point the browser to the one or other entity.
In the above SSO usecase, the technical architecture differs in the fact
that the browser can't access the SP directly. So the browser exchange
messages with the proxy only.

2) The usecases described in the technical overview illustrate that the ITS
components sits on the source site (IdP) whereas the ACS/target app on the
destination site (SP). Does it make sense to define the proxy as the source
site and the target applications as the destination site?


My gut feeling is that SP-Initiated SSO (Redirect/POST Binding) (section
5.1.2 of technical overview of saml 2.0) has the closest fit for the above
SSO solution with a proxy. The user tries to access an application (ex.
http://www.mycompany.com/myapp1) (step 1 in figure 12). The proxy notices
that there is no security context available yet. Therefore, the request
never reaches the SP (for uri myapp1). Instead the proxy challenges the
client for credentials and sends then the signed SAML Response to the ACS
of the SP. So, there is no Step 2 happening.


Does that make sense or do I divert SAML from its intended use?

Regards
Oliver Wulff








******************* BITTE BEACHTEN *******************
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.