Extend existing enterprise systems to secure cloud apps
While securing apps on cloud is common concern, customers do not want to build/change their security strategy. Let’s have a look on common problem and some of the solutions available to address this issue. Enterprise apps needs more than one security standards to secure their customers that ranges from simple form based authentication to complex and elaborate authentication schemes. Some of the common scenarios are:
- Providing authentication and remembering username/passwords for number of applications is a night mare. Such scenerios require a collaborative security scheme where a number of applications can be authenticated using a cenralized security mechanisms typically known as single sign on.
- Need to access applications across enterprise boundries has made the centralized security inevitable thereby necessitating the requirement of a new approach known as Fedaration.
Federation or Federated identity describes the technologies, standards and use-cases which serve to enable the portability of identity information across security domains. It is the management of user accounts for all possible clients and allows cleaner separation between the client, service and the associated authentication and authorization procedures.
Applying Federation Security to Cloud Applications
Enterprise apps on cloud pose challenges since the domain users will be required to access these applications outside the enterprise boundries with the same credentials and user experience as with the domain applications e.g. an enterprise user accessing timesheet application with their network credentials will expect the same to work with the cloud hosted enterprise leave application without re-login or entering different credentials.
Cloud apps are physically separated from the enterprise boundries and thus any enterprise level authentication resources like Active directory does not work directly.
Federation uses the open industry standards for enabling multi party interoperability for cross-domain; web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange which drastically improves the end-user experience by eliminating the need for new account registration through automatic “federated provisioning” or the need to redundantly login through cross-domain single sign-on.
Implementing Federation with Windows Identity Foundation
Federation can be implemented at browser, web services or service-oriented architecture (SOA) tiers using any number of ways involving the use of open source technologies (e.g. Information Cards, OpenID) and formal Internet standards like OASIS’s Security Assertion Markup Language (SAML) specification. Typical security federation architecture has three key elements:
- Domain/realm: A single unit of security administration or trust including a single organization.
- Federation: A collection of domains that have established trust which includes authentication and authorization for shared access to a set of resources.
- Security Token Service (STS): A Web service that issues security tokens; i.e. it makes assertions based on evidence that it trusts, to whomever trusts it.
The diagram below shows a common federation scenario for accessing a cloud resource after validating against an enterprise AD (Active Directory) server using WIF (Windows Identity Foundation). WIF is a Microsoft technology which provides a standard approach for building identity-based access into on-premises and cloud applications using the claims-based architecture.
User trying to access cloud app is first validate itself with organizational STS which will validate the user and return the corresponding claims; these claims will be used by the cloud application to authorize the user access.
