RE: [saml-dev] Implementation of SSO solution in intranet with proxy using SAML

[<robert.philpott@rsa.com>]

Scott describes "one way" of designing a SAML deployment as described in the tech overview.  

But there are other different physical network deployment options that are encompassed by the web sso use cases in that doc.  IMO, the SP described there was really intended to represent a "logical" component that could encompass a) the actual application server hosting the customer's app, b) possible Web Access Management (WAM) components that provide PEP/PDP/... services at the provider, and of course, the SAML SP processing components. There often times needs to be a fair amount of integration between these components.  For example, the SAML SP SSO components need to know what identity attributes that the SP application requires so it can request them from the IdP in an authn request.

One should not assume that proxies are always used in such deployments or that the SAML processing is always done out at the "proxy components" at the perimeter. IDP's/SP's can be architected/designed for multi-tier deployments where no proxies are involved.  We built our product to support many different deployment scenarios because a) some enterprises simply wouldn't deploy proxies to redirect calls from the web tier to the inner tiers and b) we didn't want to expose the trust-based SAML protocol and assertion processing (requiring access to signing private keys, etc) to attacks in the web tier.  Other than TLS certs/keys, we keep all signing key material in back-end systems. The design deployed simple SAML servlets in the outer web tier which do not do any real SAML trust processing.  The servlets simply provide the SAML service binding endpoints and make secured RMI calls to mid/backend tier EJBs where most of the SAML processing really gets done. The SAML components also interact with WAM components that also get deployed across those tiers.  When the RMI calls return, the responses include commands to the servlets instructing them what to do next (e.g. redirect to another local service endpoint, initiate an outbound SOAP request to another host, etc.).

In this scenario, then, the "logical" SP depicted in the technical overview document can physically span across multiple network tiers and include a) the actual application server hosting the app, b) the mid-tier web access management service (PEP) and SAML processing engine, and c) the outer tier SAML endpoints/bindings control servlets.

Rob Philpott | Senior Technologist | RSA, the Security Division of EMC
eMail: robert.philpott@rsa.com | Office: 781.515.7115 | Mobile: 617.510.0893


> -----Original Message-----
> From: Beach, Michael C [mailto:michael.c.beach@boeing.com]
> Sent: Thursday, January 06, 2011 7:21 PM
> To: Scott Cantor; 'Oliver Wulff'; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] Implementation of SSO solution in intranet with
> proxy using SAML
> 
> We have exactly the deployment you describe.  We have always considered
> the "SP" part to be those proxy components on our perimeter, never the
> individual backend systems - another way to state what Scott said.
> 
> Mike Beach
> Technical Fellow
> Chief Designer, Information Security
> The Boeing Company
> 
> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Wednesday, October 06, 2010 7:46 AM
> To: 'Oliver Wulff'; saml-dev@lists.oasis-open.org
> Subject: RE: [saml-dev] Implementation of SSO solution in intranet with
> proxy using SAML
> 
> > 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.
> 
> Then the target app is not an SP. SAML browser SSO is between an IdP, SP,
> and a client browser talking to both. That's it.
> 
> You can implement an SP in a reverse proxy that covers a lot of back-end
> servers, but the SAML part ends at the proxy and the rest is up to the proxy
> and the back-end to work out.
> 
> -- Scott
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org
>