Pat Patterson, Hubert Le Van Gong, both from Sun Microsystems
Goal: How to integrate identies across Java and .NET worlds using SAML, Liberty ID-FF...
Problem is typical of multiple-sign-on, exacerbated when across multiple enterprises.
Tools: J2EE security at EJB tier & Web tier. Active Directory on .NET side. How to tie them together?
Basic issues: Identification, Authentication, and Authorization.
Authentication requires user to present a credential - password, smartcard, hardware token, biometric, etc. System verifies credentials, provides short-term token representing authenticated identity. LDAP against directory server, ADSI against Active Directory.
Active Directory is an LDAP server. Simple - just point LDAP client at appropriate port on Windows server. Effective - users only have one password to remember. Limited - users are still prompted for credentials by each application.
Single-sign-on - two flavors, enterprise SSO and web-based SSO. Enterprise SSO requires client support, web SSO works with standard browsers, typically cookie-based, although other mechanisms exist. Proprietary mechanisms for mapping form session token to policy. XACML shows promise, but little mainstream takeup yet.
Web agent/proxy inserts identity info as HTTP headers accessible from HttpServletRequest. Can deploy web agent on IIS. J2EE agent also inserts identity info into EJB context. J2EE security means application code is insulated from implementation details yielding role mapping and vendor independence.
SSO improves user conveniencs, one password per session, and straightforward programming model. But SSO more complex than simply authenticated against AD, requires access management product. SSO only works within an enterprise or domain.
Desktop SSO - user experience: authenticate to operating system, browse to protected resource, gain access based on identity and policies in force. Browser leverages desktop authentication. Standards exist in GSS-API and SPNEGO. DSSO is possible on Windows, Solaris, Linux, OSX, etc.
DSSO minimizes user authentications to one, very seamless transaction. But only relevant in enterprise or intranet scenario, doesn't apply to extranet, wireless. Still need higher level authentication for high-security apps.
Web SSO using cookies has a limitation, as participating servers musts be in the same internet domain. Integrating across vendors is difficult. Federation is the way out - loose coupling, strong interaction.
Security is built from ground up, since the assumption is that communication is across the internet. Privacy is built in, mechanisms allow only need-to-know data to be revealed. Standardization ensures interoperability across vendors. B2B/B2C/B2E scenarios are well suited to this model.
SAML 1.x - Security Assertion Markup Language. Standardized by OASIS. Specifies representation of identity in XML, request-response protocols, browser-based single-sign-on. Big plus is that SAML is platform independent.
Liberty Alliance project Identity Federation Framework (ID-FF) - leveraging existing standards (SOAP, SAML, WS-Security), extends SAML's SSO - single logout, account linking, pseudonyms. Identity provider is at center of "circle of trust". LA web services framework - identity is central to web services. Also need discovery service as trusted authority and to locate services for a given principal, personal profile service provides user attributes a la LDAP, several other services plus template for defining custom services. No standard Java APIs yet, JSR196 is in progress.
WS-Federation is building on WS-* stack. Semantically similar to Liberty ID-FF. Relies on WS-Addressing, WS-Trust, WS-SecurityPolicy, WS-Policy, WSPolicyAssertion, WS-Security, WS-PolicyExchange WS-MetadataExchange WS-PolicyAttachment.
Shibboleth - open federation. Facilitated by Internet2, oriented towards .edu community. Privacy is a major design concern, actual identity of end user is often not relevant, only their attributes (e.g., affiliation with organization).
SAML 2.0 reflects convergence of much of ID-FF and SAML, also stuff from Shibboleth.
SAML 2.0 concepts: Assertions - authentication, attribute, and entitlement information. Protocols - request/response pairs for obtaining assertions and doing ID management. Bindings - mapping SAML protocols onto messaging or communication protocols. Profiles - combining protocols, bindings, and assertions to support a defined use case. Authentication context - detailed data on types and strengths of authentication. Metadata - IdP and Service Provider configuration data.
Federation and J2EE - J2EE abstraction holds - federation products abstract away complexity while leaving J2EE apps unchanged. User experience is seamless integration across disparate domains. Products can provide APIs to extract attributes from the assertion.
But what about MS and .NET? Sun & Microsoft published 2 specs in May 2005:
- Web Single Sign-On Metadata Exchange Protocol (pdf)
- Web Single Sign-On Interoperability Profile (pdf) - defines subsets of Liberty ID-FF and WS-Federation representing minimal interoperable feature set.
Many levels of integration. Tradeoff between simplicity and functionality. Standards for the wire are done, standards for Java are under construction (JSR196). Specifications for interoperability exist, but they aren't standardized yet.