One deployment scenario that keeps coming back time after time in the research or pilot programs that we hear about is the use of federation between internal groups of an organisation.

This particular use case side steps the sticky issue of do we trust our federated partner to have correctly authenticated the user, because everyone belongs to the same organisation. You can up to your colleague and inspect their configuration and deployment in order to give yourself the necessary warm fuzzy feeling.

What this use case does emphasise is how federation can be used in order to trust between parts of an organisation that don have any specific need to get full unrestricted access to each other resources. Full domain trust does allow for different business units to work more efficiently together, but you do need to be very careful with your configuration in order to prevent the guys down the hall accidentally getting access to the financial data.

The benefit federation gives you is that by default domain outsiders are denied access to resources. You have to specifically open a path for specific users to specific resources. The ability to then move on from those resources to other resources is also covered by configuration, and is also by default denied.

Let consider an example. Let say you an information provider, aggregating information relating to the sale, distribution and use of widgets. You have people out in the field selling widgets, you have warehouses stocking and distributing them, partners who manage their own accounts with you online, and you a responsible open company and publish weekly roll-up reports of regional widget sale volumes and customer satisfaction levels.

You provide all these services via an Internet visible web portal. Each user of a different type will log in and receive their service of choice, some will receive multiple services. Most of the data relating to these services is available on the internal corporate network in vast banks of databases. The sales application fills in the orders database directly. The warehouse application helps predict stock levels and allows the manager to allocate stock for delivery, and runs from the stock database together with the orders database. The partner application allows them to make their own orders and set minimum levels for stock that must be maintained in the orders and stock databases, and allows for online complaint tracking using the customer service database. The public reporting application scans through all the databases and counts up all the deliveries made in a region, and also the complaints made for that region and displays them in pretty colours. The database is locked down so that only specific users are permitted the correct read or write access to each database to perform the task at hand. These database users are backed by domain users in your corporate domain.

On top of all this you have a service level agreement that stipulates certain security, privacy and quality of service levels, and includes the promise of a single sign-on experience.

One way of achieving your goals is to have your users log in to the web portal using their domain credentials. You develop web applications for your portal and open up connections direct to the database from your DMZ. OK, yes, cringe, that is a bad example even for a starting point, but it does illustrate a point. Being a domain user in the DMZ and having direct access to resources is asking for trouble.

Let bring the resources inside then let install Citrix Presentation Server and run our applications there. Users log into the DMZ with domain credentials still, but now we only have access to the Presentation Servers, and resources are launched through web interface integration into your portal. This feels much better, but we still using domain credentials over the Internet. We introduce a security token based authentication system. Now we feel like we have a more secure system.

But wait! Re-org! Now each of the databases is owned by a different department, and each department has their own domain for the users that back onto the database. How will we get access to the appropriate databases, especially those users whose applications must access two different databases? Our users could enter multiple credentials, but no, that contravenes the SLA. Let introduce a domain trust. We make all the domains trust each other, and reconfigure the databases to allow trusted users access to the appropriate tables. Ouch. That will be complicated and expensive, and leaves room for horrible errors!

In addition your DMZ deployment has more subtle problems, it still has routes to important resources open to attackers. In a simple deployment you may have provided access to the Domain Controller in order to authenticate users. Even in a more complex scenario there will be a route to a component to which authentication is delegated. Once attackers gain access to that component then all bets are off and in they come, with rights available across the whole infrastructure.

So let back off a bit and think again. We have several departments, each with its own domain, its own database and its own administrators. We have a DMZ portal that requires services from each department. We can create a new domain in the DMZ specifically to support the portal. Authenticated users only have rights in the DMZ, they have no rights in the internal network. When a user tries to run an application that is provided by another department then a process of federation is initiated. The user is directed to their local domain to obtain a proof of authentication to present to the internal department and the proof is only valid for the specific target department and application it cannot be redeemed for alternative resources. The internal department then creates a proof of authorisation to present to the application itself and the user is granted access. If a real domain user is required for accessing backend resources such as the database then an account mapping is performed and the application runs as an underlying user, but the end user has no visibility into this. If the user wishes to use further applications then the same federation dance is done for each and every application, there are no automatic rights conferred or assumed just because the user has accessed one application.

And hey presto! We have a more secure deployment where each department has full administrative rights over their own area of responsibility and no delegated rights are needed for foreign users. Administrative changes can be made in an encapsulated environment and the administrators do not have to concern themselves with un-stated or hidden assumptions relating to trusts or cross-domain access. Everyone job is easier in the long-term, and mistakes due to complexity are less likely.

Now I realise that I glossed over a number of details to present the example, but I intentionally wish to leave plenty of scope for imagination and room for discussion.

Do you see anything familiar in this example? Does the over simplification rile you?! Do you have something to say, experience to share or questions to ask? Perhaps you have an environment that is completely unlike the simple example but you can see parallels between them. Would you like to share your thoughts about that?

They say blogs work best when they are an open conversation between real human beings. Please help me create an open and public discussion around this topic, and perhaps working together we can form some ideas on how to more easily create more secure and maintainable environments.