Implementing Pluggable Single Sign-On in MOSS 2007

The Microsoft Single Sign On Service is one of the most misunderstood and overlooked features of SharePoint. Many people think of it as a federated SSO mechanism by which one would gain a "one sign on for several applications" environment whereby all third party apps could be assimilated into the SharePoint environment using an arbitrary sign on mechanism. It's purpose is rather to integrate and connect to third party base systems, such as SAP, Siebel, or other LOB systems.

The power that it provides, when combined with the Business Data Catalog (BDC), is to eliminate the need to build complex identity impersonation in order to retrieve business data out of those third party systems. Using its structure of Enterprise Application Definitions (EAD) one can build several pass through authentication channels by which business data can easily be assimilated and brought to a web front end application through the use of various webparts, whether it is OOB, or a custom developed solution.

The Default Single Sign On Service
Single sign on in SharePoint needs to be called up by using services.msc. Once you get started, the best next step is to start to plan out how you are going to configure the accounts for SSO, which are:

• Configuration account
• Single sign-on administrator
• Single sign-on service
• Enterprise application manager

You can set the exact criteria of what needs to be satisfied for each account. After the accounts are created you will create the encrypted SSO database where we are going to map and store our third party credentials. Once your database is created, and the encryption key is created, you can create your EAD which is going to define the structure. It says exactly how the retrieval of the credentials are going to be handled.

Pluggable SSO Architecture
The Microsoft SSO Service API is independent of the specific authentication mechanisms. The unique feature of the new MOSS SSO is that the Microsoft Single Sign On service is now a pluggable feature, by which you can leverage whichever SSO provider that you would like. It may be a custom one that you have developed or one provided by a third party. When deploying your own or a third party provider, the default SSO provider, SpsSsoProvider, will no longer be used. Because only one SSO service can be used, it is a one or other choice. A MOSS administrator/architect has to decide whether they want to bind the default SSO provider or use one of their own choosing, each which carries its own implications.

© Copyright 2008, Tomas Elfving

Next Generation Portal – Federated Portals

In order to provide the user a single business platform for all enterprise resources, the user should be able access content across all portals in the enterprise. To achieve this, portals have to be integrated in such a way that content is location-transparent to users without users having to remember numerous URLS and identities for access. This is the next generation evolution for portal computing. Gartner refers to such portals as federated portal. Such federated portals need to provide federated content and identity (single-sign-on).

This posting discusses industy efforts and standardizations that drives this development.

Content (Application) Federation

JSR 168

JSR 168 is outcome of Java community process, an open forum for the development of Java standards, reference implementations and TCKs (Test Compatibility Kit). JSR 168 is very similar to Servlet specifications, the request-response presentation framework part of J2EE, the java enterprise edition middleware standard. JSR community made a decision to create a new specification for portlets. JSR 168 defines a standard for creating application markups (aggregate-able application interfaces) called portlets. It also defines a run-time environment service for portlets called portlet container and a protocol API (application programming interface) for portlet and portlet container handshake protocol.

Portal container provides lifecycle management for portlets, processes the user requests and generates dynamic content to form the user desktop. The portlet container to portlets is analogous to servlet container to servlets. Portal container leverages servlet technology and can be built on top of the servlet container. Portlet container differs from servlet container by adding presentation constructs with portlets. Presentation constructs enable the container to produce an aggregated user desktop and allows the container to send information to portlets on user actions. Presentation constructs include predefined portlet modes and window states. Since the portlets need to be personalized, container services include a declarative way of providing user information or attributes to the portlets.

JSR 168 provides declarative security model for the portlets but does not favor any single sign-on standards. This specification follows J2EE role based declarative security model for portlets. It also includes standard deployment constructs and conformance toolkit for portlet container services.

This standard achieves several milestones in portal computing. It provides:

a) A standard API for creating portlets or dynamic application content markup for portals
b) A standard container service model – Container services can be provided my as off-the-shelf system vendors (portal servers), allowing developers to work business applications
c) No vendor lock-in – portlets could be run in any containers that conforms to this standard
d) Hot deployment of new portlets and hence no down-time for new application launch
e) Support for localization and internationalization and
f) Support for multiple types of client

WSRP – Web Services for Remote Portlets

WSRP is the outcome of joint efforts of two Oasis (www.oasis-open.org, a non-profit ebusiness standards organization) technical committees, WSIA – Webservices for Interactive Applications and WSRP itself. WSRP 2.0 has been approved as standard in April 2008.

WSRP addresses the issue of location transparency for portlets. WSRP leverages webservices infrastructure for accessing the portlets hosted in remote containers. Location transparency is not new to the computing world. Several technologies were invented to do this, starting with RPC remote procedure calls. During component Object oriented paradigm revolution, DCOM, RMI, CORBA and EJB were invented to address this. Webservices is becoming the latest in this line with its advantages to work over the Internet.

WSRP defines a producer-consumer-client architecture for getting applications to user desktop. Client refers to the browser that acts as a user desktop. Consumer refers a portal server or aggregation engine that aggregates from several producers to form the user desktop. Producer can be application interfaces (other portals serving portlets or stand-alone applications) that produce markups. WSRP defines producer constructs for service producers; consumption constructs for consumers and a protocol for consumer-producer communication.

How WSRP works

Portlet state in the consumer is part of transport and hence consumer doesn’t have to maintain this state but producers can be mandated to consumer to handle session persistence. Consumer communicates to producer via SOAP (Simple object access protocol). Producer publishes the interfaces services or applications via WSDL (Webservices definition language). Consumer can lookup, register with the producers and invoke their services. Consumer maintains session with client.

WSRP defines a Portlet management interface allowing the consumers to customize the portlets and refers them as consumer configured portlets. This allows producers to cater different set of consumers by allowing themselves to be customized by the consumer consuming it. WSRP also address URL rewriting since consumer aggregates content from producers (portlets) that can be remote behind a firewall. An example of this could be third party services provider acting as WSRP producer. In this case, remote portlets may have produced URLs that point back to itself and since they are remote, the consumer (portal) would need to rewrite the client URLS. WSRP delegates the security implementation between the consumer and producer to webservices security standards

Identity (Single Sign-On) Federation

JSR168 provides standardized local portlet integration to portal desktops. WSRP allows them to be location transparent enabling applications to be shared across portals. Next issue to address is federation of declarative security systems built for portals called as Web-SSO (Web Single Sign-On).

Web-SSO model has to evolve into Federated SSO model solutions allowing user to navigate between different portal domains without having to re-authenticate. SAML exactly addresses this topic of access security inter-operability between different security systems, essentially portals.

SAML – Security Assertion Markup Language

SAML, currently in its version 2.0, specification from Oasis technical committee is an XML framework for exchanging assertions between security systems. Assertions are verification of certain facts about subjects; subject being a user or a system.

The specification has four major components:
a) assertion and request-response protocol data formats called SAML Core
b) bindings and profiles called SAML Bind
c) conformance program for SAML called SAMLConform
d) security and privacy considerations called SAMLSecure

SAML Core covers three types of assertions:
a) Authentication – Was the subject authenticated by a particular means at a particular time?
b) Attributes – Is the subject associated with supplied attributes?
c) Authorization – Can the subject access a specific resource?

SAML Core defines a request-response protocol called SAML protocol between assertion artifact (token) issuing party and the relying party. Relying party asserts with Issuing party about user log-ins, attributes and authorization credentials. Specification is designed in such a way that this request-response protocol can be used in several scenarios and leverage transport protocols for communication. In SAML terms, scenarios are referred to as SAML Profiles and transport protocols for communication are referred to as SAML Bindings.

Perspectives

JSR 168 will allow application developers to write portlets allowing integration with any Java-based portal server providing container services. It will also create a market for portlets. Microsoft Web parts is a competing, proprietary but successful, technology on the .NET platform.

WSRP adoption is emerging and has the potential to be the standard that bridges the Java-.NET gap.

WSRP and JSR 168 is set to enable Content federation.

Adoption of SAML by identity market is evident as vendors have rush to implement this. IBM Tivoli, Oblix, Sun, SiteMinder, Securant, Evidian, Entrust, Netegrity, RSA Security, Baltimore technologies, Sigaba, Verisign are some to name a few. SAML browser profile compliant Access Security System is set to address Security Federation
Examining the relations between these standards, JSR 168 does not mandate WSRP but refers it to remote portlets. WSRP does not mandate JSR 168 portlets but JSR 168 fit right as portlet standard in the java world. Since WSRP does not mandate JSR 168, application (markups/portlets) can be aggregated between both .NET and Java. WSRP not directly need or mandate SAML, but the need for SAML arises in the case of federated single sign-on. SAML does mandate SOAP over HTTP in its implementation.

The missing link - Federated SSO for webservices

Taking a closer look, missing standard is federated SSO for webservices. WSRP rely on webservices standards and hence federated SSO would be necessary to consume a WSRP producer produced portlet, protected by a different Web-SSO system. Example of this could be someWSRPConsumer.com portal accessing a portlet on someWSRPproducer.com and both the portals have their own Web-SSO systems.

SAML was designed smart to allow applications with different scenarios. Webservices security model standards could use SAML for achieving this federation. WS-Security, security language of webservices created by IBM and Microsoft defines a SAML profile for SOAP messages. WS-Security is not discussed in detail in this posting. WS-Security is yet to become an open standard but under consideration. WS-Security SAML profile can provide federated-SSO for webservices.

Conclusion

Portal has evolved as a user-centric application integration platform. It has become a strategy rather than solution implementation.

Federated Portals is poised to become the next generation concept for portal computing. Content and Identity federation will become the key technology enablers for federated portals. Without the standards, this will become a pipe dream. JSR 168/Web parts, WSRP and SAML are set to achieve these goals. Co-existence with federated content and identity standards will become one of the key selection criteria for all off-the-shelf web solutions.

In order to reach to the next generation, businesses would have to conduct assessments to identify federate-able portals. The value of consolidating infrastructures for application and content delivery has proven in case of portals. Federation follows its footsteps at the enterprise level avoiding multiple user identities even between portals, eliminating the need for same application launches on different portals. In some cases, such federation model can even become business opportunities. An example of this could be an enterprise participating in the federated ebusiness eco-system acting as a service provider.

Planning, Choosing, Aligning and Governing were the key elements of a successful portal implementation. In case of federated portals, challenges are no longer at the departmental levels, but at the higher level, enterprise-wide.


© Copyright 2008, Tomas Elfving