Microsoft Partner Enablement – Cloud OS

Over the past few years we have seen a massive shift within business infrastructure with regards to I.T dictating the services, whereas now users are demanding more and more, from anywhere, on any device. This transition has caused many a headache, compatability, compliance, training, time, the list goes on. Microsoft have researched these trends have devised solutions around the 3 core infrastructure components –

Compute – Processing/Memory

Storage – SAN/NAS

Network – Switching/Routing

Surrounding these 3 key infrastructure areas, these components can be utilised in many different ways and because of this, providing services that allow self-service and on-demand generation is a key area for the design of the Cloud OS.

Cloud Computing – The ability to host, store and migrate services to and from the cloud.

New social and app patterns – Applications for business and social designed for all devices from anywhere.

Consumerisation of I.T – The demands of users for services from the I.T department (of which needs to ensure compliance with the Business)

Data Explosion – Ensuring data is properly stored for DR and backup, businesses are generating more and more and expanding beyond current onsite infrastructure requirements.

Microsoft’s Cloud OS takes all of these ingredients on board and provides solutions from the one platform;

Customers

Azure

Service Providers

The one platform approach is such a massive selling point from anyones point of view, simply having one login for all these services makes it an extremely valuable option. Having to ‘manage’ accounts isn’t the best job in IT and doesn’t innovate the I.T team (speaking from a managed services prospective) so the better Microsoft can make this all encompassing package, the better for most managed service providers. As an example, several accounts do not need to be maintained, you simply federate your domain with Microsoft and the cloud services will simply refer back to your onsite Active Directory infrastructure to complete the authentication.

The one platform approach goes down further into the hierarchy and as such covers the following;

Development – Developing from one platform for many differing devices is a huge incentive for any business.

Management – Ability to control aspects of devices and services provided to users (regardless of the device they access it from).

Data – Ensuring recoverable data stores and high availability to access at any point in time regardless of ‘outages’.

Identity – Having one login for all services enables a simple solution for users – “I need this…..” – “Then, please login here”

Virtualisation – Enabling a robust and highly available infrastructure to manage and maintain without downtime is key in today’s society.

Infrastructure Requirements – ADFS

At a minimum, deploying AD FS 2.0 within a single organisation requires the following infrastructure:

 

  • Active Directory – AD FS 2.0 requires Active Directory to authenticate users. This can be any version of AD, and does not require a specific schema revision, or domain or forest functional level.

 

  • Active Directory Federation Services 2.0 – Deploying AD FS in a single organisation requires a minimum of one AD FS 2.0 server. In its simplest configuration, this server will be configured with a claims provider trust to the corporate Active Directory (this is configured by default on every AD FS 2.0 server), and a relying party trust for each application that will be consuming claims produced by this AD FS server. By default, internal users will authenticate to the AD FS server via Integrated Windows Authentication in order to obtain AD FS tokens that they will present to any relying party applications. A single AD FS server can authenticate users in the same domain as the ADFS server, in any domain within the same Active Directory forest, and any users in any trusted forest.

 

  • Domain Name System (DNS) – The DNS requirements for the WebSSO deployment are fairly straightforward. All clients must be able to resolve the A record of the federation server and any relying party applications, in addition to the DNS requirements associated with Active Directory authentication (SRV records, and so on). If a Federation Server proxy (FSP) has been deployed, this will potentially add to the DNS requirements in this scenario.

 

The Federation Server As a Claims Provider

To summarise this particular post;

  • The Claims Provider presents a web service that can issue security tokens containing claims in a standardized format (SAML – Security Assertion Mark-up Language)
  • The Claims Provider allows administrators to publish policy data about the claims provider, which a relying party federation server can retrieve and use as part of the federation relationship.

The federation server is a computer that runs a security conscious service that issues security tokens.

When the federation server is given the role of a Claims Provider (CP) it allows authentication capabilities; whereas in the Relaying Party (RP) role it acts as a passage that allows identities to travel between different security boundaries.

In the case of Office 365 – Active Directory Federation Services (AD FS 2.0) is the Windows Server role that provides this federation server functionality. In this implementation, ADFS can fulfil either of the above functions – Claims Provider or Relaying Party.

As a Claims Provider;

  • Processes requests from incoming users to provide signed tokens containing claims that represent the user’s digital identity.
  • Claim information can consist of – user’s name, role or group membership etc.
  • ADFS issues tokens in a SAML format.
  • ADFS can protect the contents of security tokens in transit by signing and encrypting them.

Side note – ADFS 2.0 allows you to encrypt tokens, previous versions were only digitally signed.

As a Relaying Party;

  • Receives tokens from a trusted Identity Provider.
  • Will issue new security tokens that a local application can consume to make authorisation and personalisation decisions.
  • By using a relaying party, organisations such as Microsoft are able to provide ‘Single Sign-On‘ (SSO) for Office 365, crossing the boundaries between ‘signing on locally’ and authorising use within the ‘cloud’.

The two above terms can be further defined as follows;

Claims Provider – An organisation that is responsible for the user identities in a federated relationship. (In our examples this will be the organisation with the Active Directory infrastructure (onsite))

Relaying Party – The organisation that is responsible for administering and protecting the web-based resources and other claims-based applications. (In our example this would be the cloud- Office 365)

Working together

In a Federation Trust Relationship, the Relaying Party is the partner that trusts (or relies on) a Claims Provider to authenticate users, this takes the process of user authentication from the applications and web services that are managed by the RP. The RP consumes the claims from the CP, which it verifies through, typically, a PKI certificate.

%d bloggers like this: