Working with standards provides many benefits. For example, your organisation will not have to reinvent the wheel, you support a wide range of international products and you create transparency about your processes.
At Connectis, we not only support these standards, we actively contribute to their further development. For instance, we take part in the OASIS technical committees regarding the future of SAML and XACML and we share our experiences in establishing trust networks such as DigiD, eHerkenning and eID with OIX.
Security Assertion Markup Language
Security Assertion Markup Language (SAML, pronounced “sam-el”) is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee.
SAML assumes the principal (often a user) has enrolled with at least one Identity Provider. This Identity Provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).
Thus, a service provider relies on an identity provider to identify a principal. At the principal’s request, the identity provider passes a SAML assertion to the service provider. On the basis of this assertion, the service provider makes an access control decision.
- A user requests access to a protected resource.
- The user is not logged on to the site.The Service Provider sends the user to the Identity Provider’s log on service, together with a SAML request for authentication (AuthN-request).
- If the user is not already logged on to the Identity Provider (or if re-authentication is required) the Identity Provider asks the user for credentials (e.g., user name and password) and the user logs on. Additional information about the user may be retrieved from the user data store for inclusion in the SAML response.
- The Identity Provicer’s log on service returns a SAML response (containing the authentication assertion and any additional attributes) back to the Service Provider.
In essence, the SAML request for authentication (AuthN-request) and the response (Assertion) are transported via the user’s browser, using standard HTTP-post or redirect bindings. This means, that the user can see the messages that are sent back and forth.
Compare it with teacher-parent communication that is done by passing notes through the hands of the child. The child can see what is written, but he cannot alter the information without it being noticed by the parent or the teacher. To add authenticity, the notes could be signed by the teacher.
In SAML, this is done by signing the messages using an XML (X509) signature, the public keys of which are exchanged out of band (in the metadata).
eXtensible Access Control Markup Language
The standard defines a declarative access control policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defined in policies. As a published standard specification, one of the goals of XACML is to promote common terminology and interoperability between authorization implementations by multiple vendors.
XACML is primarily an Attribute Based Access Control system (ABAC), where attributes (bits of data) associated with a user or action or resource are inputs into the decision of whether a given user may access a given resource in a particular way. Role-based access control (RBAC) can also be implemented in XACML as a specialization of ABAC.
The XACML model supports and encourages the separation of the authorization decision from the point of use. When authorization decisions are baked into client applications (or based on local machine user id’s and Access Control Lists (ACLs)), it is very difficult to update the decision criteria when the governing policy changes. When the client is decoupled from the authorization decision, authorization policies can be updated on the fly and affect all clients immediately.
The latest version 2.0 was ratified by OASIS standards organization on February 1, 2005.
The first committee draft of XACML 3.0 was released April 16, 2009.
Simple Cloud Identity Management
The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It’s intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud.
Public Key Infrastructure (X509)
A public-key infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates.
In cryptography, a PKI is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique within each CA domain. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA). The RA ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation.
Web Services Federation
WS-Federation is an Identity Federation specification, developed by BEA Systems, BMC Software, CA Inc., IBM, Layer 7 Technologies, Microsoft, Novell, Ping Identity, and VeriSign.
Part of the larger Web Services Security framework, WS-Federation defines mechanisms for allowing disparate security realms to broker information on identities, identity attributes and authentication.
Web Services Trust
WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.
The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.
Using the extensions defined in WS-Trust, applications can engage in secure communication designed to work within the Web services framework.
WS-Trust defines a number of new elements, concepts and artifacts in support of that goal, including:
- the concept of a Security Token Service (STS) – a web service that issues security tokens as defined in the WS-Security specification.
- the formats of the messages used to request security tokens and the responses to those messages.
- mechanisms for key exchange
WS-Trust is then implemented within Web services libraries, provided by vendors or by open source collaborative efforts. Web services frameworks that implement the WS-Trust protocols for token request include: Microsoft’s Windows Communication Foundation (WCF) and Windows Identity Foundation (WIF), Sun’s WSIT framework, Apache’s Rampart (part of axis2), and others. In addition, vendors or other groups may deliver products that act as a Security Token Service, or STS. Microsoft’s Access Control Services is one such service, available online today. Ping Identity Corporation also markets an STS.
OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication. The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the ‘relying party’). An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
The OpenID protocol does not rely on a central authority to authenticate a user’s identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique URI, and are managed by some ‘OpenID provider’ that handles authentication.
OpenID authentication is now used and provided by several large websites. Providers include AOL, BBC, Google, IBM, MySpace, Orange, PayPal, VeriSign, LiveJournal, Steam, and Yahoo!.
OAuth is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically supplying username and password tokens instead. Each token grants access to a specific site (e.g., a video editing site) for specific resources (e.g., just videos from a specific album) and for a defined duration (e.g., the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.
OAuth is a service that is complementary to, but distinct from, OpenID.
XML Signature (also called XMLDsig, XML-DSig, XML-Sig) defines an XML syntax for digital signatures and is defined in the W3C recommendation XML Signature Syntax and Processing. Functionally, it has much in common with PKCS but is more extensible and geared towards signing XML documents. It is used by various Web technologies such as SOAP, SAML, and others.
XML signatures can be used to sign data–a resource–of any type, typically XML documents, but anything that is accessible via a URL can be signed. An XML signature used to sign a resource outside its containing XML document is called a detached signature; if it is used to sign some part of its containing document, it is called an enveloped signature; if it contains the signed data within itself it is called an enveloping signature.