Using external IAM or the portal platforms OOTB security functions?

I've done a few posts on the IAM/portal subject (http://blog.tomaselfving.com/2008/10/security-architectures-for-portal.html, for instance) and there is surely a lot to gain from separating the access management and the identity management functionality from the portal platform and its web applications. On the other hand, an IAM platform is a huge investment both to buy and to implement as it requires expert product competence.

So, what are the arguments for choosing an external IAM platform?

In my opinion, if You have requirements for...

1. Several login methods, especially login methods not found in portal platform products.

2. Protecting more than one appllication, especially applications on different platforms (i e web applications and SAP)

3. SSO between applications on different platforms, both web and other apps.

4. High security requirements can in itself motivate an IAM-platform, as you may move the portal platform inside the DMZ and only have the reverse proxy on the DMZ.

5. Protecting a SOA environment of web services as well as web applications may be an interesting scenario for an IAM solution

...then, You may go ahead and evaluate IAM products to compliment your portal platform.

And finally, look carefully at the quality of the adapters between the IdM products and your portal product. It will be in the interface between the IdM and the portal that You will find the toughest challenges of the integration work. If this interface is poorly constructed, the IAM implementation may end up limiting the functionality of the portal platform!

© Copyright 2008, Tomas Elfving

Implementing Sharepoint security

There are two major approaches to implementing Sharepoint security:

1. AD groups
Create Active Directory groups for each site collection and optionally each subsite and object that will require unique permissions. Create a new SharePoint OU (Organizational Unit) within Active Directory. Put these new groups in this OU. Then add these groups to their corresponding SharePoint groups in SharePoint (Owner, Member and Visitor). Adding users to the AD groups may also be done through an externa identity management application.

Advantages: Control, as all changes to security happen in Active Directory. It is easy to add/update/delete people from groups. No individual user accounts are stored in SharePoint with regards to security.

Disadvantages: Extra setup work. Each site you create a new site collection or a subsite/object that requires unique permissions. You have to set up Active Directory first and then add the groups to SharePoint. If your SharePoint administrations and your Active Directory administrators are different people, they have to cooperate.

2. Sharepoint groups
Ignore Active Directory groups and let the SharePoint administrators and site collection administrators add people directly to the groups provided by SharePoint.

Advantages: Easier admin as it lets the SharePoint administrators quickly change security without needing to involve the Active Directory administrators. It's also easier to see the names of everyone that has the permissions for a SharePoint group right from the interface instead of having to go to the Active Directory administrators and having them look it up.

Disadvantages: Maintainability suffers. You can have individual user accounts all over your SharePoint farm and not know who has permission to what. Out of the box, SharePoint does not provide a tool that shows you all the permissions a specific user account has (although there are 3rd party tools that provide this). When someone leaves or you need to move their account between departments, for example, it can be time-consuming to update the permissions in SharePoint.

The first approach is clearly the better practice in my opinion.

External Access/Identity management
With companies setting up external Access management/Identity management platforms, you also need to look into how the Sharepoint security architecture maps into the corporate access/identity management architecture. Typically, You want to use the IdM application to tie users to groups (either AD or Sharepoint groups, both are possible). This way, both internal and delegated administration can be provided. Delegated administration can be offered for extranet partners to manage their own users for instance.

© Copyright 2008, Tomas Elfving

Security architectures for portal platforms revisited

Do you want to secure more than one application? Manage identities efficiently? This post describes on a high level access and identity management solutions managing the security functions for a portal platform.

This pics shows an RSA implementation, but similar solutions can be set up using any of the leading AM/IdM products:



Identity management
The idea is to centralize the authentification, authorization, administration and delegation of user identities (to create, update, delete and block user accounts) and access control of to user data to a company-wide common platform of reuseable components, instead of doing that in each and every application. For instance, a user’s address may be changed and the identity management solution immediately propagates that into every application and system integrated by the identity management solution. In extranet solutions you may even delegate the user management of a partner company’s users to a superuser in the partner company’s organization by making the identity management solution accessible on the internet (this scenario requires the identity management solution to be used in conjunction with an access management solution).

Separating login methods
Login methods (such as userid/pwd, digital certificates, smartcards etc) may be added to a separate login service. The access management platform ties different login methods to different applications. By choosing this way, you don’t use the built-in security functions of the portal product at all. You trust the access management platform to secure all portal applications. The access management platform may also be used to secure a web services environment in a SOA architecture implementation. Yet another scenario is to secure both an existing web site and a new site during migration.

Web portal application integration
One problem is that editors and developers of web portal applications needs to work in their portal platform (MOSS 2007, for instance) when creating groups and giving access to various resourses of their web application. It might also be complex with rolebased access rights and other fine grained access solutions. You need some interface definition and integration solution between the Identity management solution and the portal platform.

I suggest having the portal platform responsible for creating groups and access rules for resources. The IdM then extracts the groups. In the IdM You add people to the groups which will give them correct access to resources when logging into the web portal application via the Access Management component (which integrates to the IdM as well).

© Copyright 2008, Tomas Elfving

Thoughts on SOA Governance

Some advice when it comes to the creation process of (web) services for a SOA platform:

1. Only create services from core business logic/funktioality. Where is an overhead in terms of work requiered creating and mainatining web services so focus on the ones most important for your business

2. Bigger is better. Only the really big services qualify as SOA services for reuse througout a company.

3. Don't make a services per function. Again, bigger services with mony functions is easier to reuse and maintain.

4. Document each service separately from other development documentation. That makes the documentation of the service more accessible to its users and to people whating to make changes later on.

5. Create unique SLA's for each web service. The reason is that each web service may be used in different applications with different requirements.

When it comes to management of SOA I believe it's a good idea to separate creation from maintenance of services. I suggest you separate SOA governance in two parts:

1. Create services - The initial decision when you choose what will be a SOA web service and what doesn't is taken by the company's IT architecture board.

2. Change management of services - When a service is changed it may affect others, therefore a Change Control Board for SOA is necessary. That board controls any changes in webservices and they prioritize the development work.

© Copyright 2008, Tomas Elfving

SSO between a MOSS and a Weblogic web site

The problem

I need to set up single-sign-on between two web sites. The new site is in MOSS 2007. I am migrating to the MOSS-based site from the existing old site that is built in BEA Weblogic with a SUN One web server in front. The MOSS site requires login. The existing site contains applications requiering login (using the Weblogic realm). It is too expensive to migrate the entire site to MOSS at once, so we need to do a migration in several steps having both the old and the new site in production during the overlapping time.

Proposed solution

I am considering IFrameing the existing applications into the new MOSS-based site while migrating them one by one. The problem is that I cannot expect the user first to log on på the MOSS-site and then to logon to the IFramed applications residing on the existing Weblogic site, so we want SSO between them. I am considering using ISA Server (or maybe another Access management product) to achieve this. With ISA Server the both servers need to be in the same domain and use the same Web listener. I think the solution looks good on paper, but the devil is, as always, in the details. I'll write more on this when I have tried this out in reality. If You have any experience on something similar, i'd appreciate any comments on this!

© Copyright 2008, Tomas Elfving

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

Hotfix for SharePoint group target audience issue available

As one reader pointed out (thanks!), there is a Microsoft Office SharePoint Server 2007 post-Service Pack 1 hotfix out now adressing an issue that I wrote about in a post last year. The symptom appears when You add Active Directory user accounts and Active Directory group accounts to a group in MOSS 2007. When you designate the SharePoint group as the target audience for a specific Web Part, some user accounts in the SharePoint group cannot access the Web Part.

Check out the hotfix!

© Copyright 2008, Tomas Elfving

Poor integration between Oracle Webcenters portal and content management tools

The built-in CMS in Oracle Webcenter (UCM), formerly Stellent, is very powerful for building and maintaining ”information-heavy" sites with its great document management and workflow features. The problem is that the UCM has no portal and portlet integration functionality.

To edit the site structure of a web portal application (change meny items or order, add/remove portal web pages and change portlets on web pages) You have to use the development environment (typically JDeveloper). Then You have to rebuild and redeploy the web application onto the target production environment. This means that web site editors are restricted to edit content in an existing site structure, otherwise they have to engage developers to build and deploy. A very time- and resourceconsuming process. These type of changes simply shouldn't require a re-deploy in my opinion. Competing portal products have better solutions. Also, it is obviously a disadvantage to have to work in two separate tools with content updates.

I have heard mixed messages from Oracle regarding this, I have both got information saying that they will fix this, but I have also heard argumentation from Oracle experts that this "flexibility" is an advantage!

© Copyright 2008, Tomas Elfving

WSRP 2.0 support in MOSS and Oracle WebCenter

The long-awaited (5-6 years since WSRP 1.1...) approval of the WSRP 2.0 specs have arrived. Microsoft have promised support for it in MOSS 2007, probably by adding an OOTB Web part working as WSRP 2.0 Consumer (the product has a WSRP 1.1 consumer today). No time plan for that work have been communicated though. I have also evaluated Oracle's Webcenter recently and it turns out WebCenter uses WSRP 2.0 for all portlet-to-portal container communication, even in cases where the portlets resides on the same server as the portal container!

. © Copyright 2008, Tomas Elfving

Using the WSRP 1.1 Consumer Web part in MOSS 2007

Having Java/JSP apps too expensive/timecomsuming to migrate to MOSS 2007? Maybe the apps works just fine as is, and the migration adds no business value. Besides IFraming them, the way to go is WSRP. Check out this architecture picture:


Package your existing apps as WSRP producers and use the MOSS OOTB Web part acting act a WSRP 1.1 consumer. Some advice on the way:

1. Keep portlets simple - In general for MOSS and WSRP, if you keep the portlets fairly straightforward, you should not run into problems. If you start to use a lot of script, DOM modification, AJAX calls, etc. then you may run into issues.

2. Start small - I would try a “real” part of the application that includes navigation, form submission, script, user identity, session state and persistent state.

3. Namespacing - Microsoft WSRP implementation is not great. MOSS uses an IFrame to implement it’s WSRP browser side container so you typically do not have to be concerned with namespacing. In fact, you may run into problems if you try and use “wsrp_rewrite” prefix (consumer namespace re-writing). There is a bug in their namespacing. You may need to rely on producer namespacing instead (if you plan on consuming those portlets elsewhere or back in your Java Portal server).

4. Test - Thoroughly test WSRP functionality in MOSS first to uncover issues first.


© Copyright 2008, Tomas Elfving

Java/.NET web service interoperability issue regarding checked exceptions

Using web services as integration technology is an obvious choice when service-orienting your companys IT architecture, especially when having a mixed Java and .NET environment. One strategy many companies choose is to package business logic in Java-based web services while developing web user interfaces on the .NET platform.

The problem

There is one interoperability issue that I'll like to shed some light on, and that is "checked exceptions". Checked exceptions is userdefined exceptions. Java supports this construct whereas C# doesn't. The C# development team have chosen to exclude checked exceptions by design (why? -> pls read the interview with the lead C# architect Anders Hejlsberg at http://www.artima.com/intv/handcuffs.html). This imposes a risk of having unhandled exceptions. A java-based web service may throw checked exceptions that the .NET-based client is unaware of. The .NET client developer needs to manually analysis the WSDL file to see what type of exceptions the web service method may throw. This is a tedious and error-prone way to work compared to the Java/Axis that autogenerates a complete interface including exceptions in object-form on the client side.

The solution

C# doesn't support checked exceptions by design, but Windows Communication Foundation supports automatic analysis of the WSDL-file when creating the proxy on the client (you must use svcutil.exe, not wsdl.exe. Svcutil.exe is default in Visual Studio 2008, but not in 2005. Or run on the command line). Exceptions are serialized in objects that can be analyzed and handled on the client without needing to parse XML-strings for error codes and messages. The exceptions are catched in regular try-catch blocks just as any other .NET Exception. This way, you get type safe userdefined exceptions. You'll also get the "intellisense" in Visual Studio on exception objects.

© Copyright 2008, Tomas Elfving

Security architectures for portal platforms

[16 oct 2008 - There is a new better version of this post at http://blog.tomaselfving.com/2008/10/security-architectures-for-portal.html. 

Regards, Tomas]

Do you want to secure more than one application? Manage identities efficiently? This is a first post in a upcoming series around the subject of security in terms of access and identity management solutions managing the security functions for a portal platform.

The idea is to centralize the authentification, authorization, administration and delegation of user identities (to create, update, delete and block user accounts) and access control of to user data to a company-wide common platform of reuseable components, instead of doing that in each and every application. For instance, a user’s address may be changed and the identity management solution immediately propagates that into every application and system integrated by the identity management solution. In extranet solutions you may even delegate the user management of a partner company’s users to a superuser in the partner company’s organization by making the identity management solution accessible on the internet (this scenario requires the identity management solution to be used in conjunction with an access management solution).

Login methods (such as userid/pwd, digital certificates, smartcards etc) may be added to a separate login service. The access management platform ties different login methods to different applications. By choosing this way, you don’t use the built-in security functions of the portal product at all. You trust the access management platform to secure all portal applications. The access management platform may also be used to secure a web services environment in a SOA architecture implementation. Yet another scenario is to secure both an existing web site and a new site during migration.

© Copyright 2008, Tomas Elfving

Setting multivalue properties in User profile

More on User profiles; MOSS 2007 supports multivalue properties in the User profiles, but how do you set these fields? The this[] operator on the UserProfile object returns an ArrayList called UserProfileValueCollection. This code example shows you how to add multiple values to a multivalue property:

Add references to Microsoft.Office.Server, Microsoft.SharePoint and System.Web in your Microsoft Visual Studio project.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Office.Server;
using Microsoft.Office.Server.Administration;
using Microsoft.Office.Server.UserProfiles;
using Microsoft.SharePoint;
using System.Web;

namespace UserProfilesDemoApp
{
class UserProfileProgram
{
static void Main(string[] args)
{
using (SPSite site = new SPSite("http://servername"))
{
ServerContext serverContext = ServerContext.GetContext(site);
UserProfileManager userProfileManager = new UserProfileManager(context);
UserProfile userProfile = userProfileManager.GetUserProfile("domainname\\username");

// Insert your database access code here to get the values to set!

userProfile["MyInterests"].Add((Object)"Soccer");
userProfile["MyInterests"].Add((Object)"Icehockey");
userProfile.Commit(); }
}
}
}
}

© Copyright 2008, Tomas Elfving

Master and supplementary data sources in Sharepoint 2007

The user profiles are a neverending source of issues, it seems! Get e-mails with all sort of questions regarding populating and using the user profile. Today, I’ll address the concept of master/supplementary data sources.

The basics
The User profile store contains the user account property information. This information is obtained by importing it from a directory or a data source that contains user accounts. MOSS 2007 can import a list of domain users from the Active Directory directory service, LDAP server, or the Business Data Catalog. In addition, you can write code against the object model to import information from other directory services or applications. You can schedule regular imports to the user profile store, and these can be incremental or full.

Master and supplementary data sources
But what if you need more data fields in your user profiles than your Active directory contains? What if you for instance have additional data in database or retrieved by a web service that you want to use for personalization or audience targeting? Office SharePoint Server 2007 treats Active Directory and LDAP directories as master connections for importing user information; that is, it can use them as a source to create user profiles. This master connection is responsible for adding and removing users from the user profiles database.
To add supplementary user profile info you use one or several supplementary data sources. They cannot add or remove users (like the master connection), but they can provide additional user information not available in the master connection. A Business Data Catalog data source is a typical supplementary data source.

There is a "preliminary" sample under way at http://msdn2.microsoft.com/en-us/library/ms585895.aspx. Also check out http://blah.winsmarts.com/2007-4-SharePoint_2007__BDC_-_User_Profiles.aspx.

© Copyright 2008, Tomas Elfving

Portal platform with integrated ”e-legitimation” login for processoriented organizations and businesses

To celebrate the re-launch of Heimore Groups site at www.heimore.com, I’d like to take the opportunity to give You a brief about one of our “software-as-a-services” - ExpressPortal.

Note: e-legitimation is the Swedish digital ID solution, commonly accepted by governmental organizations, banks etc.

ExpressPortal - A Portal platform with integrated ”e-legitimation” login for processoriented organizations and businesses

ExpressPortal is a ready-to-run portal framework solution for both intranet and external users. The solution features all the out-of-the-box functionality that you’d expect in a modern portal platform (enterprise search, content management, personalization, role- and target group based interaction for instance). The Heimore Group ExpressPortal solution is tested and ready-to-run with built in components for digital signatures, e-legimitation access control, authorization and SSO (other access control systems can also be plugged-in).

ExpressPortal builds upon an open, scalable and extensible architecture based on market-leading portal products dedicated to openness and portal standards such as Web parts, JSR 168/268 and WSRP, which makes the portal platform easy to integrate to and from. It has an open architecture making it ready to use to implement portals and applications building on services in a SOA-based environment to support processoriented businesses and organizations.
The solution contains a framework to efficiently assemble portals and applications. It features out-of-the-box templates for common eServices and applications, preinstalled integrations with digital signatures and e-legitimation, content management and typical business processes.

Curious? E-mail me for more info, or check out the (only swedish at the moment, sorry for that, translation is in the making) ExpressPortal whitepaper, and our other packaged services named ExpressInfrastructure.

Figure 1: The ExpressInfrastructure Architecture

© Copyright 2008, Tomas Elfving

Hosting the Windows Live Messenger IM Control

It is very easy to integrate the Microsoft Live Messenger Control like I have done on this blog. Just follow the steps described in the MSDN article at http://msdn2.microsoft.com/en-us/library/bb936683.aspx.

© Copyright 2008, Tomas Elfving

Office SharePoint Server 2007 Capacity Model now shipping

System Center Capacity Planner 2007 has shipped, now with two New SharePoint deployment models!

• Office SharePoint Server 2007 Capacity Model
• Windows SharePoint Services 3.0 Capacity Model

By supplying information such as...

• number o users
• internet vs. intranet,
• distribution between anonymous vs. authenticated users
• usage profiles (Light <-> Heavy publishing, Light <-> Heavy collaboration)

...you get planning help and high level guidance regarding topology and hardware requirements. You can analyze how your deployment may be impacted by a merger or other scenarios and variabels.

This tool simplifies the hardware acquisition and address some of the early number of server licensing type questions. Note artificial limits have been placed in the tool to limit it at 100,000 users and 3 TB. Above these limits, Microsoft recommend MCS or experienced Architects be consulted. Even up to these limits it's recommended to consult with experienced architects and consultants to validate the recommendations from the tool. Also, check out the HP capacity planning tool to validate these results.

I took the tool for a spin. For a single-site minimum topology for a light publishing/light collaboration internet site with 50% anonymous and 50% authenticated users, the following spec is recommended:

Topology
Sites with servers: 1
Sites with clients only: 0
Total number of clients: 1

Site: Mini
Number of users: 1
Number of servers: 4
Number of SAN connections: 0

Server: Index Server
Processor: 2-processor, 2,40 GHz, Opteron (2-chip x 1-core)
Minimum memory: 8,0 GB
Disk: DiskArray 1\Volume 1 (File System), 144 GB RAID 5 (3 x 72,00 GB SCSI 10 000 RPM)
NIC: 1 x 1 000 Mb/s
Roles: Index

Server: SQL Server
Processor: 2-processor, 2,40 GHz, Opteron (2-chip x 1-core)
Minimum memory: 16,0 GB
Disk: DiskArray 1\Volume 1 (Log Files), 146 GB RAID 1 (2 x 146,00 GB SCSI 15 000 RPM)
DiskArray 1\Volume 2 (Data Files), 584 GB RAID 10 (8 x 146,00 GB SCSI 15 000 RPM)
NIC: 1 x 1 000 Mb/s
Roles: SQL Server

Server: Web Front End 1
Processor: 2-processor, 2,40 GHz, Opteron (2-chip x 1-core)
Minimum memory: 8,0 GB
Disk: DiskArray 1\Volume 1 (File System), 146 GB RAID 1 (2 x 146,00 GB SCSI 10 000 RPM)
DiskArray 1\Volume 2 (File System), 144 GB RAID 5 (3 x 72,00 GB SCSI 10 000 RPM)
NIC: 1 x 1 000 Mb/s
Roles: Web Front End; Query Server

Server: Web Front End 2
Processor: 2-processor, 2,40 GHz, Opteron (2-chip x 1-core)
Minimum memory: 8,0 GB
Disk: DiskArray 1\Volume 1 (File System), 146 GB RAID 1 (2 x 146,00 GB SCSI 10 000 RPM)
DiskArray 1\Volume 2 (File System), 144 GB RAID 5 (3 x 72,00 GB SCSI 10 000 RPM)
NIC: 1 x 1 000 Mb/s
Roles: Web Front End; Query Server

Personally, I think this seems a bit much... I mean isn't 4 double-processor servers as a minimum startup configuration a bit steep? It obviously depends on your availability requirements, but if You can skip the redundancy, You should be fine with 2 servers (one web and one database).

© Copyright 2008, Tomas Elfving

Massive support for OpenID

I've over the last months done a number of posts on the emerging de-facto standard for internet authentification OpenID. Now the OpenID Foundation is announcing that Google, IBM, Microsoft, VeriSign and Yahoo! have taken seats as the organization's first corporate board members.

OpenID is appealing as it allows users to authenticate their identity through a single chosen provider instead of creating unique accounts at every website you use. Today, more than 10 000 web sites and 350 million users use OpenID.

For users, OpenID means much easier account creation, better personalization, privacy and security when trying out new web sites. It makes for a greatly improved user experience. For websites and other companies, OpenID means more and happier users and potentially greater access to information about those users.

There's a whole lot of momentum right now for OpenID. As I've previously told, in January Yahoo! increased the number of OpenID enabled user accounts by orders of magnitude, the long-awaited OpenID 2.0 spec was just recently finalized and the entire Data Portability paradigm is moving into the public consciousness quickly.

All of that said, big vendors have a lot of short term interest in controlling identity silos. It won't be easy to get their long term interests in openness to prevail. Fortunately, they are participating but are in the minority on the OpenID Foundation board.

There are many, many places you can get an OpenID and there are significant differences in advanced feature sets. To get a good look at the range of options and details beyond mere simple one-way authentication, check out the vendor comparison at SpreadOpenID.org.

© Copyright 2007, Tomas Elfving

Security features in MOSS 2007

MOSS will often be implemented in an environment with an existing corporate-wide access management solution handling identity management, authentification and authorization. They typically work on a URL level for web applications. MOSS web applications will need to make good use and cooperate well with IAM/IDM solutions. This article looks at security features available in MOSS 2007 explaining the tools available on the portal level to leverage these technologies.

1. Pluggable Authentication Provider
An authentication provider is a component that lets you verify user credentials. The authentication provider is an important security component when setting up Internet-style SharePoint® authentication. MOSS supports the Windows®-based authentication methods available in previous SharePoint versions such as Integrated and Basic authentication, forms-based authentification as well as plain-text userid/pwd. You can add multiple authentication providers so that, for example, internal users log in via Windows authentication while external users do so with a separate, pluggable provider.
MOSS is built upon ASP.NET 2.0, which enables the use of pluggable authentication providers. This lets you use configurable directories for storing user information as long as there's an ASP.NET 2.0 membership provider (and optional role provider) that corresponds to the member data store. Pluggable provider credentials can be hashed, encrypted, or stored in plain-text depending on the node values stored in the machine.config file that correspond to the membership provider. Several membership providers are available for use with MOSS, some of which include an LDAP V3 membership provider, plus a SQL Server™ membership provider and Active Directory® membership provider (available with ASP.NET 2.0). Using the ASP.NET 2.0 membership architecture, it is feasible to create custom providers that use membership stores like Oracle databases, XML files, or even flat text files. A custom authentication provider inherits from the ASP.NET MembershipProvider interface, which in turn inherits from the ProviderBase class (see Figure 1).


Figure 1: .NET Membership Class hierachy

Note that those services related to crawling and indexing content, must use a Windows account even when using a pluggable provider.

2. Forms-Based Authentication and Web Single Sign-On
Forms-based MOSS authentication is based on ASP.NET 2.0. It utilizes pluggable authentication and role providers to enable Internet-style security mechanisms that don't restrict customers to an old-fashioned NT login prompt. Instead, you can build a customized login process geared toward your users' needs. To protect the authentication process further, forms authentication cookies and authentication tickets are encrypted and tamper-proof.

The form identity provider does not have to reside locally and can, in fact, plug into an external identity management system, which in turn would provide the validation of the user credentials. This functionality is known as Web single sign-on, and it employs an HTTP module for external authentication. In such a scenario, you can federate identities between your organization and business partners whereby they are able to use their own organizational logins to authenticate to your MOSS implementation.

3. Encrypting MOSS Application Connection Strings
It's not good a security practice to place valuable connection string information in plain text in a web.config file. The exposed information could enable a user to create an object instance to the SQL database server and manipulate valuable data. However, using inherent ASP.NET 2.0 functionality you can encrypt the data using either of two available technologies: Windows Data Protection API (DPAPI) or RSA encryption. DPAPI capitalizes on the built-in cryptographic functionality of Windows to encrypt and decrypt using the MOSS server machine key. RSA encryption lets you use public key algorithms, but carries the added overhead of needing appropriate containers for the encryption keys.

Using encryption does have some consequences. Because you are using the local machine key for encryption, you can only use this configuration node on the MOSS server it was created on-otherwise the cipher process will fail. If an intruder gained access to the server, they could retrieve the machine key and decrypt the connection string. The decryption process will also cause a minor application performance hit.

4. Alternate Access Mapping and Zones
Alternate Access Mapping (AAM) is useful when setting up more than one entry location for your MOSS environment. AAM simply enables you to specify different URLs through which users can access a single physical site (see the diagram in Figure 2). AAM can direct users to the same physical path for your MOSS site, but with different authentication providers and Web application security policies. AAM also compensates for using different domains, reverse proxies, and other URL redirection mechanisms. The URL that MOSS will use is already mapped for you by default, but this can be extended to additional URLs that a SharePoint architect explicitly creates to handle different methods of entry. AAM is required to ensure that proper internal and public URL mapping works correctly.


Figure 2 URL Mapping and Zones

In MOSS, zones are a new feature that allow greater control over the site mapping provided by AAM. Zones let you map different authentication providers to the same physical path and MOSS content depending on the AAM URL mappings through which users are connecting to the content. When specifying AAM URL mappings, although it is not necessary that the zone is bound to an authentication mechanism, it is recommended. An AAM URL mapping to a zone that is not defined in the authentication providers page will use the security setting for the Default zone.

Zones do require some planning since they will heavily impact how people are authenticated and routed through your portal from multiple URL entry points. When extending a new Web application, you can specify the zone you want to use under the Load Balancing URL section of the settings (see Figure 3). It is recommended that you place your most publicly accessible URL (for example, the URL you plan to expose to the Internet) in the Default zone, as this is the URL SharePoint will use if it cannot fully determine which zone you are in.

Within each zone you can bind a global Web application security policy that defines permissions settings for users in the zone. This lets you centrally manage large-scale permissions modifications. Web applications commonly include several sites in various site collections, and permissions management of these sites can become problematic when applications become large and complex. MOSS 2007 allows global security policies that bind policy settings such as full access, full read access, deny-write access, or deny-all access to a specific user or group within the application. These policies can override the granular permission settings provided by MOSS and managed from the SharePoint Central Administration interface, so you'll want to plan your configuration carefully.

Bringing this all together, your externally facing site might have two URLs as defined in your AAM settings: one for your corporate users to enter, and a second for external users. Each has a unique URL-perhaps contoso for internal users, and extranet.contoso.com for trusted external partners. While both of these URLs will map to the same content, each can access the site through its own zone, with its own authentication provider and its own application security policy. Configuring the intranet zone on the internal URL lets internal users resolve to their domain-authenticated Windows identities while external partners log in via Web single sign-on authentication through the extranet zone, which allows them to use their own organization's user credentials. By leveraging the power of binding Web application security policies to zones, it becomes possible to give all trusted external users full-read access, as opposed to manually setting it on an object-by-object basis.

5. Targeted Content Locking down your SharePoint site collections means users will only handle information you authorize them to access. New flexible permission mechanisms allow you greater control over the various types of business information stored in your MOSS environment.

MOSS 2007 gives you the option to bind an identity to a specific object, whether a site collection, an individual site, a document library, a subfolder, a list, or an individual document or list item. This enforces granular access controls and explicit membership to that item, both denying access and adjusting the user interface so that users are unaware of items they don't have access to. This functionality in MOSS is known as Item Level Security (ILS) or Secured Objects (SO).

6. Integrating Pluggable Single Sign-On The MOSS SSO service provides an encrypted back-end cache of users' credentials for mapping to connected line-of-business systems. This can aid in the retrieval of business-critical information to display through MOSS mechanisms such as the Business Data Catalog (BDC) or SharePoint DataView Web Parts (DVWP).

The MOSS SSO provider, like several of the other application architectural features discussed, is pluggable; you can specify a unique SSO provider outside of the one shipped with MOSS (SpsSsoProvider), though only one SSO provider per line-of-business system can be registered at a time within the environment.


© Copyright 2007, Tomas Elfving