Archive for the ‘IAM’ Category

SCIM – System for Cross-domain Identity Management


SAML, OAuth, and OpenID Connect, as we have seen, all require the registration of the Client Applications, the Resource Owners (End Users), and the Resource Servers. The Authorization Server (AS) = The OpenID Provider (OP) is thus forced to keep the registration data, perhaps stored in tables. While these standards loosely define what goes into these tables, they do not define either how they are collected nor how these data are managed. SCIM, the System for Cross-domain Identity Management [not to be confused with SCIM the Smart Common Input Method platform] is an attempt to do this. See Ping Identity’s history in their SCIM white paper and a brief Wikipedia article for descriptions of some early attempts. The IETF lists some current draft specs.

The “C” in SCIM used to stand for “cloud”, but on-premises use of SCIM for internal identity management is popular as well. A SCIM server can be in the cloud and still manage on-premises applications using a secure SCIM channel through the firewall. This becomes a “cloud identity bridge”.

In my earlier IAM posts, I noted that the IdP or the AS had table descriptions for Clients, Resource Providers, Resource Owners, etc. This is the beginning of a Schema for SCIM. It needs groups, roles, entitlements, devices.


OpenID Connect


OpenID Connect allows Client Applications to verify the identity of the End User based on the authentication performed by an Authorization Server. It also allows the Client to obtain basic profile information about the End User.

There are a number of versions of how OpenID Connect was born, e.g. here, here, here, and officially here. I like the story that after multiple influential companies implemented SAML, WS*, and OpenID 2.0, and also Facebook implemented Facebook Connect, Eran Hammer and David Recordon put forth a one page proposal for what became OpenID Connect. I can’t find this historical one-pager, and even the core spec today is around 100 pages with half a dozen other supporting documents. Some have called it a functional merger of OpenID and Facebook Connect that is layered on OAuth 2.0. Others provide the “formula”:

(Identity, Authentication) + OAuth 2.0 = OpenID Connect

Whoever should be getting historical credit, the basic idea is both simple and brilliant: Take the authorization mechanism of OAuth 2.0, make a couple tiny additions, which I’ll explain in a moment, and viola, we’ve got a authentication mechanism.

As with OAuth 2.0, there is a registration process that is not specified, but it is essentially the same as for OAuth and is described in the spec under OpenID Connect Discovery and under OpenID Connect Dynamic Client Registration. There is a bit of a pas de deux on terminology. What OAuth calls the Authorization Server AS is also referred to as the OP for OpenID Provider, and OP has an Authorization Endpoint and a Token Endpoint. The client obtains these endpoints during registration.

The fundamental new idea is simply to add a new scope value openid to the initial authorization request message (described in my last post on OAuth 2.0) to the Authorization Server AS. Having openid as one of the scope values, makes requests not only for access tokens but also for a new “identity token” and also opens up the possibility to request more information about the end user. Here are some of these request parameters:

  • scope: must contain the new value openid and may contain one or more of the scope values of profile, email, address, phone, and offline_access
  • response_type: code – means both access and id tokens be returned from the token endpoint in exchange for the code value obtained from the AS
  • client_id: obtained during registration at the AS
  • redirect_uri: one of the pre-registered redirection URI values for the client

This request asks the AS to authenticate the owner/operator of the browser that is sending the message and to return an id_token as well as access_tokens. The id_token will affirm that the user has authenticated recently. The id_token may contain additional claims or information about the user. The method of authentication is not defined by the spec. The id_token includes a JSON object that includes:

  • iss = issuer identifier for the issuer of the response
  • sub = subject identifier, a locally unique within the issuer for the end-user
  • aud = audience(s) for whom this id_token is intended = array of case sensitive strings or a single such string
  • UserInfo Endpoint
  • iat = Issue timestamp
  • exp = Expiration datetime
  • auth_time = time end-user last authenticated
  • How the user was authenticated (optional)
  • many other optional tags

The user runs a protected application which may make additional GET requests to the UserInfo endpoint for REST APIs for identity attributes. Curiously the spec warns that these claims may not be for the end user (due perhaps to man-in-the-middle attacks)! In addition there are language dependencies on the claim values.

The final OpenID Connect specification is dated Feb 26, 2014; and the certification program was launched April 22, 2015 with Google, Microsoft, Ping Identify, ForgeRock, Nomura Research Institute, and PayPal the first to self-certify.

Multiple companies, in support of OpenID Connect, have announced they will no longer be supporting OpenID 2.0 at some point in the near future.

My next IAM post is about SCIM.  It is here.

OAuth 2.0


After SAML, a study of IAM needs to dig next into OAuth 2.0. It is NOT backward compatible with earlier OAuth versions, and an excellent historical introduction is here.) The official spec is RFC 6749, as well as the spec RFC 6750 for Bearer Token Usage. This post is to present an easy overview by working a specific and common example.

OAuth 2.0 is for authorization, but there is a rather clever extension, OpenID Connect, that provides authentication. They really should be just one standard, and I suggest learning them both in rapid succession.

One primary motivation for OAuth was to provide authorization for the many APIs that are provided vendors such as Google, Facebook, Linkedin, Twitter, and eBay to enhance and extend their products. These vendors view mobile devices as emerging to be the primary user interface, and hence much attention in OAuth is made to support a wide variety of such devices with varying capabilities and security profiles.

OAuth 2.0 has four actors:

  • Client C = the application making protected resource requests on behalf of the resource owner and with its authorization. C is a client both of the resource server RS and of the authentication server AS.
  • Authorization Server AS = the server issuing access tokens to the client after successful authentication of the resource owner and obtaining authorization. AS has separate authorization and token endpoints.
  • Resource Server RS = API = the server hosting the protected resources. RS is capable of accepting and responding to protected resource requests that use access tokens.
  • Resource Owner RO = an entity capable of granting access to a protected resource. When the RO is a person, RO = end user.

Clients. The popularity of OAuth stems from the huge variety of client applications directly supported. Individual implementations of authorization servers vary in how they support clients, but the spec gives some guidance. There are two broad client types, confidential and public. Confidential clients are capable of maintaining the confidentiality of their credentials and can authenticate securely. Public clients cannot, e.g. executing on a device used by the RO that is incapable of secure client authentication. The AS should assume the client is public until it meets the AS’s criteria for secure authentication. E.g.,

  • A web application that is a confidential client running on a web server. An RO accesses the client application via a browser on the device used by the RO. Client credentials and access tokens are stored on the web server and are not accessible by the RO.
  • A user agent based application is a public client in which the client code is downloaded from a web server and executes within a browser on the device used by the RO. Protocol data and credentials are accessible to the RO.
  • A native application is a public client installed and executed on the device used by the RO. Protocol data and credentials are accessible to the RO, but are protected from other servers and applications.

Client Registration. Before initiating a request for data, a client application registers (over TLS) with the AS, typically with an HTML form filled out by some end-user. This mechanism is not defined by OAuth. The point here, however, is to establish trust by exchanging credentials and to identify client attributes such as the redirection URIs and client type. The trust established must be acceptable not only to the AS but also to any relying resource server that accepts AS access tokens. Registration can be accomplished using a self-issued or third-party-issued assertion, or by the AS performing client discovery using a trusted channel.

A client identifier is issued by the AS to the client at the time of registration. It is a string, unique to the AS and to the client. Each client registration record in the AS typically includes:

  • client identifier (the key to this record) = client_id REQUIRED
  • client password
  • client public key
  • client secret = client_secret REQUIRED
  • list of redirection URIs
  • other attributes required by the AS: application name, website, description, logo image, acceptance of legal terms, etc.
  • client type

If the client is implemented as a distributed set of components, each with a different client type and security context, e.g. a confidential server-based component and a public browser-based component, then the AS must either have specific support for such a client, or should register each component as a separate client. This flexibility of a particular AS can be a competitive advantage for it.

OAuth gives some additional security guidance to the three examples of clients mentioned above. Web applications, confidential clients accessed by the RO via a browser, should store their access tokens on the web server in a way not exposed to or accessible by the resource owner. User-agent-based applications, public clients whose code is downloaded from a web server, should make use of the user-agent capabilities when requesting authorization and storing tokens. These are accessible to the RO. Native applications, installed and executed on the RO’s device, have protocol data and credentials accessible to the RO. Native applications should protect these data and tokens from hostile servers and other applications, even those that execute on the same device.

The registration process must also include RO and RS registration. It includes the authorization endpoint that the client uses to obtain an authorization grant. Each RO registration record in the AS should contain:

  • username
  • password
  • public key
  • certification of authenticity
  • session cookie info
  • authorization endpoint (“application/x-www-form-urlencoded”)
  • URI for the associated RS
  • access token requirements for RS

As mentioned above, one of the things that makes OAuth 2.0 popular is its flexibility to support a wide variety of devices from traditional workstations and servers to Internet enabled devices such mobile phones and wrist watches. The protocol flow for various instances of device varies in order to deal with various client capabilities. The spec gives some guidance, but the implementations vary. The additional layer OpenID Connect addresses this in more detail.

A typical protocol flow is the one specified for a confidential client C requesting authorization for a specific resource on RS:

  1. C requests authorization from RO
  2. C receives authorization grant from RO
  3. C sends authorization grant to AS
  4. C receives access token from AS
  5. C sends access token to RS
  6. C receives protected resource from RS

It is required that these exchanges use TLS.

A. In this example, the authorization request in (A) is made directly to RO. Without sending its client_secret, C sends and the RO receives this request as a JSON object that includes:

  • a list of redirection URIs via the “redirect_uri” request parameter which must be registered with the AS and formatted using the “application/x-www-form-urlencoded” format.
  • This request may include a “state” parameter and value.
  • A client_id obtained during registration of the client.
  • An authorization request number
  • Authorization Endpoint
  • Response/Grant type requested. REQUIRED. Since there are multiple authorization grant types, there is some variation on authorization requests. Cf. grant types below.

B,C. The authorization grant in (B) and (C) is one of the following four predefined grant types or an extension/custom grant type private to this particular AS:

  1. Authorization Code – Used when the AS is an intermediary between C and RO
  2. Implicit – for clients implemented in Javascript in a browser. Client is issued access token directly w/o an auth. code
  3. resource owner password credential – username/password is the auth. Code to get an access token
  4. client credentials – used as a grant when the client C is acting on its own behalf
  5. extension/custom grants

B. The Resource Owner might not have the capabilities to process the request or to form the grant. In this case the RO forwards the request to the AS which returns the grant to the RO after processing. The RO then returns the grant to the client C. A good example here is when the RO is an end user with a small mobile device, and the RO, running an application on C, asks C to do something such as print a photo owned by RO but stored in the cloud. C says, ok, but I need access to the photo, and starts step (A) with a resource request. Since the request contains the authorization endpoint, the RO can immediately forward the request to the named AS which can do all the processing needed to produce the grant. (The perspicacious reader might ask, well if the grant gets sent to C in step (B) and then back to AS in step (C) with a request for an access token, why doesn’t AS just return an access token? The point is to formally separate the steps that require client credentials from the steps that require RO credentials.)

B,C. Note authorization grants do not include RO credentials. As our example, let’s look at the Authorization Code grant type. It is a JSON object containing at least:

  • grant type, in this case, grant_type: authorization
  • authorization end point
  • client id
  • RO id
  • requested scope
  • local state
  • redirection URI
  • the client generated authorization request number

D. AS authenticates C and validates the grant. If valid, AS issues an access token as well as a refresh token. A synonym for access token is bearer token. It is also called a “valet key”, because it provides limited access to resources much like a valet key for an automobile. These tokens are JSON objects defined by RFC 6750 containing:

  • Type name: Bearer
  • grant type
  • client ID
  • scope
  • timestamp when issued
  • validity time for this token in seconds beyond timestamp
  • original client generated authorization request number
  • authorization code (unique number)
  • authorization end point
  • RO id
  • RS id
  • RS endpoint
  • signature of the AS
  • refresh token number

These token attributes are not fully specified by the spec. Anybody in possession of this token will be given access to the protected resources by the RS. Thus, tokens should be protected from disclosure both in storage and in transit.

E. The client C requests the protected resource from RS by presenting the access token for authorization.

F. RS validates access token by checking scope and validation (expiration) date, and serves request.

An example of such an access token is:

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache







If the token has expired, C submits the refresh token, its client_id, and its client_secret to AS to get a new access token, and then C repeats (E) and (F).

When an RO provides a distinct C with access to resources, this access is authorized by AS and provided by RS. I think of AS as being a big flat space supported by three legs C, RO, and RS. This is dubbed a “three legged flow”. When is client equals the resource owner (or is entrusted with the RO’s credentials), then the roles of C and RO collapse, and we have a “two legged flow.” This special case can be handled by a resource owner password credential grant type or a client credential grant type.

Finally, quite a number of security concerns are addressed in OAuth 2.0 Threat Model and Security Considerations [RFC 6819]. These security concerns are also discussed in OpenID Connect which is my next post here.

Introduction to OAuth 2.0, OpenID Connect, and SCIM


The development of SAML dates from January 2001. As discussed in an earlier post, SAML 2.0 provides a Single Sign On (SSO) authentication and authorization protocol that many view as applicable primarily for federations of enterprises. Mobile applications and dominant Internet applications such as Salesforce, Facebook, Google Apps, Linked In, etc. were providing more or less independent and light-weight “micro-services” fronted by APIs. SAML was deemed too heavy-weight to be supported by such APIs.

By 2014, authentication, authorization, and delegation (of authorized rights) for APIs, are embodied in the standards OAuth, OpenID Connect, and SCIM. These standards call for authentication and access tokens encoded in JavaScript-like Object Notation JSON rather than SAML’s (somewhat more verbose) XML. These JSON tokens are then passed in HTTP headers.

OAuth 2.0 has evolved to be a base technology for authorization, but it’s hard to do authorization without knowing to whom or to what you’re giving rights, and thus authentication sneaks in to the standard. To better address this, OpenID Connect has evolved from earlier versions of OpenID and other security work done by vendors to become a layer on top of OAuth 2.0 for authentication. It would seem that these two standards should merge.

While the proponents of OAuth and OpenID Connect predict that they will eventually supersede SAML, this doesn’t seem likely in the near future as SAML seems to do quite well for enterprises with existing relationships such as supply chains and portals. In addition, there are some use cases where the co-existence of SAML, OAuth, and OpenID Connect seems natural in spite of some duplication of functionality.

Finally SCIM, the System for Cross-domain Identity Management, addresses cross-domain identity management and specifically provides REST APIs for provisioning, change, and de-provisioning, all of which lie outside the realm of OAuth and SAML. SCIM adds considerable complexity to identity management systems, and I’m a little nervous that the initial implementations will have security problems. On the other hand, neglecting these functions is probably worse for security.

My next few IAM posts will discuss the latest versions for each of OAuth, OpenID Connect, and SCIM. I’ll also work an example of co-existence with SAML. The OAuth 2.0 post is next. It is here.

SAML 2.0 – Secure Assertion Markup Language


SAML 2.0 is one of several protocols used today to support Internet Single Sign On (SSO). It is a rich, some would say “heavy duty”, protocol with hundreds of pages of documentation [1, 2, …]. This post is an overview/introduction.

SAML 2.0 defines three parties: a principal (user) U, a service provider SP, and an identity provider IdP who exchange authentication and authorization data encoded in XML statements, which are sent from one party to another using a binding [2] such as HTTP or SOAP.

SAML statements consist of assertions and queries. An assertion is an XML statement of the form

<saml:Assertion ..> … </saml:Assertion>.

As usual in XML, the double dot consists of modifiers and the triple dot consists of child elements that further define the assertion. This XML statement is interpreted as: an assertion A issued at time T by issuer I regarding subject S provided conditions C are valid. The XML modifiers and child elements define, in particular, A, T, I, S, and C.

There are three types of SAML assertion:

  1. Authentication assertions that assert to SP that S authenticated with IdP at time T using method M.
  2. Attribute assertions about S having (attribute_name, attribute_value) properties.
  3. Authorization decision assertions that assert S is permitted to perform action A on resource R given evidence E.

For example, some of the relevant assertion child elements defined are <saml:AuthnStatement>, <saml:AttributeStatement>, <saml:Subject>, <saml:Issuer>, and <saml:Conditions>.

Correspondingly there are three types of SAML queries:

  1. Authentication query
  2. Attribute query
  3. Authorization decision query

Now you might think (as I initially did) that SAML 2.0 would have an XML query statement that corresponds to the XML assertion statement. Sorry, it doesn’t exist! Instead, SAML 2.0 defines the following protocols for how SAML elements are packaged within queries and responses and how they are produced and consumed:

  1. Assertion Query and Request Protocol – to request new and existing assertions. The Request form asks for an existing assertion by referring to its assertion ID. The Query form asks for new or existing assertions by subject and statement type.
  2. Authentication Request Protocol – for a user to retrieve authentication assertions. Used when redirecting a user from an SP to an IdP when a security context for the user is needed at the SP.
  3. Artifact Resolution Protocol – to go from reference (artifact number) to value. Allows assertions to be passed around efficiently by reference.
  4. Name Identifier Management Protocol – provides mechanisms to change the value or format of a principal’s name identifier; informs SPs that names and name formats are changed
  5. Single Logout Protocol – kills all sessions provided by a session authority.
  6. Name Identifier Mapping Protocol – maps user identities across different SPs.

The saml: XML prefix in SAML 2.0 marks the assertion name space. Similarly, the samlp: XML prefix marks the protocol namespace. There are five other prefixes: ds:, xenc:, xs:, and xsi: respectively for digital signatures, XML encryption, the default namespace, and schema related markup.

Queries use the samlp: prefix and look like

<samlp:AuthnRequest> requests <saml:AuthnStatement> assertions

<samlp:AttributeQuery> requests <saml:AttributeStatement> assertions.

<samlp:ArtifactResolve> requests a <samlp:ArtifactResponse>


<samlp:AttributeQuery ..>




<saml:NameID ..>


<saml:Attribute .. FriendlyName= “givenName”>



Here Issuer is requesting the attribute whose FriendlyName is givenName for the subject whose email address is The double dots represent additional modifiers. This query is sent to an IdP via a binding, and the IdP must return to the Issuer a saml:AttributeStatement assertion inside a <samlp:Response>.



<saml:Attribute .. FriendlyName= “givenName”>

<saml:AttributeValue ..>





Filling in the double dots, the Response overhead to match query numbers with the response numbers, the binding overhead, the Statement IDs, the Status codes, etc. isn’t difficult, but they all make the SAML 2.0 specification long and tedious. Fundamentally, SAML 2.0 needs to be flexible enough to deal with multiple name stores (X500, Active Directory, LDAP, etc.) as Issuers, multiple applications as Service Providers (SPs) that have different needs, multiple IdPs, the metadata that identifies SPs and IdPs, multiple data formats, multiple Conditions, multiple encryption, hash, signature, and certificate methods, etc. In addition, SAML 2.0 defines profiles, which describe in detail how assertions, protocols, and bindings combine to implement use cases. For me, it seems like the different profiles add possibly unneeded complexity, but good people worked on SAML 2.0 for a long time and undoubtedly determined that this complexity was necessary.

SP initiated authentication

The Service Provider, SP, initiates the authentication process using a <samlp:AuthnRequest> … </samlp:AuthnRequest> statement to the identity provider IdP. The flow goes like this:

  1. Via a browser, the user requests access to a resource on Service Provider SP.
  2. Assuming the user has no security context, SP sends the user an HXTML form that contains a <samlp:AuthnRequest>.
  3. The user issues a HTML POST request to the SSO service at the identity provider IdP with the AuthnRequest.
  4. The SSO service at IdP validates the request and responds with an XHTML form that contains a <samlp:Response ..>…</samlp:Response> which contains Issuer, Status, Signature, Subject, etc. info needed by the service provider SP.
  5. The user issues a HTML POST request to the assertion consumer service at SP containing the AuthnResponse.
  6. The assertion consumer service at SP processes this response and creates a security context, and redirects the user to the target resource.
  7. With this security context in place, the user again requests the resource from SP,
  8. The request is granted.

When a security context is in place, steps 2 through 7 can be skipped.

IdP initiated authentication

When the client wants to explore certain areas of the web, it can request authentication by an IdP associated with such an area. After authentication and the establishment of an acceptable trust relationship, the IdP can give the client a list of trusted portal web sites through which the client can pass for further exploration. Examples might be certain military or political areas, areas for certain types of private information such as photographs or private financial transactions, and even restricted research areas.

Registration and Trust Models

Sometimes registration is called provisioning. Prior to any authentication or authorization tokens being created, the IdP needs both users and service providers to register in such a way that there is a trust relationship established that is satisfactory to all of the parties. Usually this involves each party accepting the other’s certificate which comes from a chain of trust whose ultimate root is trusted.

Each IdP thus obtains a list (or database) of SPs for which there is mutual trust. Also, each SP thus obtains a list of IdPs that it trusts and that knows what it needs for authentication and authorization.

SAML 2.0 has many interesting use cases, about which there will be future posts. My next IAM post is here.

Identity Providers (IdPs) and Identity Management


The identity management problem is complex and getting more and more complex as the Internet evolves. Within a corporation there are multiple users that have multiple roles. Any given user needs to access several public, multi-tenant resources on the Internet, e.g. public clouds, public backup systems, public SaaS applications, and other services. A user most likely has multiple devices from which such access is needed from multiple locations around the world. In addition each individual user may have several security contexts from which authentication is needed; for example, the user’s company, personal use, charitable organization, little league sports team, etc. As we’ve discussed before, a username and password for each combination of device, context, resource is a totally unmanageable situation from many perspectives. Throw in privacy concerns and bad actors who steal and misuse identities, the computing industry has a serious identity problem.

Inside a federation of multiple Service Providers, multiple corporations of users, multiple types of name directories, and multiple Identity Providers, what makes for a good Identity Provider? More generally, in the context of the federation, what makes for a good Identity Management System?

At the highest level, users want unfettered (and secure) access to lots of Service Providers (SPs). When you see a commercial IdP advertised, usually the first marketing statement is the number of “applications” it supports, and of course, there are a few big ones like, Office 365, and Google Apps that are essential. It is not unusual for an IdP to advertise “thousands” of applications. Some applications want strong authentication, some use only certain protocols or data formats, etc. A user’s corporation may insist on the integration of a particular name service, e.g. Active Directory, LDAP, RADIUS, Tivoli Directory, etc. The IdP is in the middle and must support at least those combinations that the customer needs.

Thus, at the next level, the key things one wants an Identity Provider to do are also listed in the marketing material for various IdPs:

  1. Authenticate a user in multiple ways, e.g. extra security questions, hardware frobs, difficult passwords, email, SMS, Telephony, X.509, PIN, Common Access Card (CAC), government Personal Identity Verification (PIV) card, smart card, bio-metric readers, Yubikey, LastPass, KeePass (open-source), etc.
  2. Pass this authentication around (“credential mapping”) the federation without having the user re-authenticate unless additional authentication is needed (as opposed to re-authentication); support OpenID Connect, SAML 2.0, WS-Trust Security Token Service (STS), and others
  3. Allow service providers to require different levels of authentication based on risk or on the importance of the service: user IP address, IP reputation, group membership, geo location and geo-velocity. Support black and white lists to override risk algorithms
  4. Support multiple user devices, incl. Mobile
  5. Multiple application types (SaaS, Web, Internal, Mobile, …)
  6. Support various name services: AD, LDAP, JDBC, ODBC, Sun One, Novell eDirectory, Tivoli Directory, JBoss Web services, RADIUS, etc.
  7. Support Single Sign On (SSO) via SAML 2.0, OpenID Connect, Kerberos Key Distribution Center (KDC), …
  8. Security auditing, XDAS
  9. Identify anomalous user activity
  10. Participate in the enterprise disaster recovery with high redundancy

Some final thoughts about security: Many users, myself included, have been skeptical about the security of an Internet-wide Single Sign On facility. Such a service would be a juicy target for nefarious hackers. Passing around tokens on semi-secure channels appears to invite “pass the hash” and “man in the middle” exploits. The more functionality that an IdP product has, the more opportunity for bugs that open security holes. The more personal identifying information that a product holds, no matter how encrypted, the more inviting a target the IdP becomes. In addition, users should worry about who owns the encryption keys and how they are managed. Some vendors are obtaining security certifications such as SSAE 16, SOC 2 or ISO/IEC 27001. A vendor that gets such a certification is not only thinking about security, it is doing something about it.

My next IAM post is on SAML.  It is here.

SSO – Single Sign On


Early time-sharing systems provided a security model for the underlying file system that provided many services with a single log-in. Access to any branch of the file system was determined by its “ownership” via the familiar Read, Write, Execute flags for Owner, Group, World.

It wasn’t too long before Owner, Group, World was too restrictive and Roles/Groups were introduced where any user could belong to multiple Roles/Groups and access was determined by the least restrictive flag for the Groups to which that user belonged.

Clusters of very similar machine types and operating systems, often with a high speed interconnect between the machines and their devices permitted single sign-on to the systems in the cluster. Several system vendors provided proprietary clusters.

Microsoft Windows Domains pushed the cluster idea out to the LAN, where multiple LAN vendors had already pioneered single log on to the LAN. Microsoft Windows Primary and secondary Domain Controllers on the LAN synchronized user identity data to provide single log on to the domain for every user. We used Domains in our office when we still had a modem connection to the Internet. With time, however, the Internet eventually providing reasonable speed access to application/service servers around the world, such applications proliferated. There seems to be no end to the creativity of application developers on the web. But now users were having to provide separate log on authentication data for each application or service. In the small this was manageable, however it wasn’t too long before what NIST has called “password fatigue” set in. Internet users, wanting to access multiple services, started to

  • write down their (service or web site) usernames and passwords in documents, spreadsheets, and even on yellow Post-its stuck to their monitor.
  • re-use usernames and passwords
  • use overly simple passwords
  • cheat with the same username (often an email address) and simple passwords both of which are used across multiple applications and services
  • let their applications remember usernames and passwords, often in world readable cookies on the workstation.
  • Lose their usernames and password and ask system administrators (or special privileged software) to re-issue them for the user with imperfect memory.

Aside from being an expensive administrative mess, using multiple usernames and passwords was and still is decidedly insecure. Wouldn’t it be better if a user could sign on to a single service, which in turn could provide automated sign on to application/service servers? Well, yes and no. If such an “identity server” were compromised, then all of its user clients could be totally compromised. On the other hand, great care would probably be given to the construction of such a server, to the secure use of connections to it (e.g. via the latest SSL/TLS), and to the encryption of identity data held within it. With some care, this “IDaaS” could also support mobile devices, business partners (e.g. those in a supply chain), and even the Internet of Things.

The above diagram shows an Identity Provider, IdP, which services multiple application service providers, and multiple clients. This diagram implies that the multiple users belong to the same enterprise with a common Name Server and a common IdP. While it would make for a messier diagram, users from multiple enterprises that need to share applications could also be supported.

Provisioning. The users request application provisioning, either as an initial sign-up or as the first time the application is used. The IdP not only provisions the user, but also learns the protocols by which the user (and IdP) can communicate with the application. This includes learning the type of tokens the application will accept for authentication.

Such complexity tends to bloat IdP implementations, and different schemes for lightweight (or “lighter weight”) identity servers have been proposed that take advantage of existing name servers, identity managers, etc. Some vendors split up their implementation into multiple products. For example, some vendors define bridge products that translate one protocol or token format to a different one. History shows that this complexity will pass as standards converge and server speeds increase making full functionality in a single IdP product fast and scalable. Such optimism aside, there are at least a dozen vendors of Single Sign On identity providers today that address this complexity to varying degrees. Each product comes with its own system integration problems that an enterprise must weigh as it selects a Single Sign On vendor.

When a vendor collapses the IdP and the Name Server into a single product, the result can be interesting. When this product is placed in the cloud, it can be even more interesting. Some security companies have such a product, as does Microsoft with its Azure Active Directory.

I see a lot of “sign on with SocialSite” buttons on various vendor sites. The superficial idea is to allow your SocialSite to be an IdP for you. Pick your favorite half dozen social sites, and one is probably listed. There is a privacy issue here: Signing on with SocialSite gives the vendor access to all the information on your social site. This may be ok, but then again, you may not want that vendor or its customers to be grabbing information off your site or worse, posting information to your site. For me at least, I never log in using a social site.

My next IAM post is here.

JSON – JavaScript Object Notation


For reasons that are inexplicable to me, JSON is not a subset of JavaScript. The reason is a few weird non-escaped characters. Cf. RFC 7159. JSON is a language independent data format. A formal definition and parsing libraries for various programming languages can be found on Briefly JSON’s data types are:

  • Number – a signed decimal number with optional fractional part and optional exponent E part. JSON numbers are typically implemented as double precision floating point numbers.
  • String – zero or more Unicode characters bracketed by double quotes. A backslash is the escape character.
  • Boolean – true or false
  • Array – ordered list of zero or more values of any JSON type, delimited by square brackets, and separated by commas.
  • Null – an empty value null.
  • Object – an unordered set of comma separated name:value pairs delimited by braces. It is recommended that the names be unique Strings in order to implement associative arrays.

JSON values are: number, string, array, object, true, false, and null. Whitespace characters are: space, tab, line feed and carriage return. Whitespace can be used around and between values and punctuation.

Recent identity management standards (but not SAML) use JSON to encode

  • JWT tokens
  • JWK keys
  • JWE encryption
  • JWA algorithms
  • JWS signatures

Subtle points: JSON doesn’t distinguish various implementations of Number, e.g. support for signed zeros, under and over-flows, integers, etc. There is no support for JavaScript data types of Date, Error, Regular Expression, Function, and undefined (other than null.) Even being careful with escapes, so that even though properly escaped JSON values are JavaScript values, the use of eval() is not recommended. Use JSON.parse() instead of eval().

The next IAM post is Single Sign On (SSO) here.