I recently put together a glossary of common security-related terms to aid in discussions around "Single Sign-On" scenarios. I've experienced this a few times now -- a level-set on terminology is almost always needed to make security discussions productive from the start. Oftentimes the terms are confused, misused, or ambiguously defined. I have attempted to stay general with the definition of terminology, however, since I'm a Microsoft consultant the examples and products mentioned are Microsoft's.
User
A person using a system through a user interface (as opposed to a system).
Credentials
A set of claims used to prove the identity of an entity (typically a User). They contain an identifier for the client (a "user name") and a proof of the client's identity (a "password"). They may also include additional information, such as a third-party digital signature, indicating that the issuer certifies the claims in the credential.
Authentication
The process of identifying an individual based on evidence provided. Evidence may be presented in the form of credentials such as a username - password pair, pin numbers, access codes, or a hardware device such as a smart-card, or thumb-print reader.
Multi-factor authentication implies use of more than one distinct method of authenticating a user. Often, two-factor authentication is based on “something the user knows” as well as “something the user has”, such as password plus a cryptographic device.
Individuals who have not (yet) authenticated with a system are commonly referred to as anonymous users.
Authorization
Authorization is the process of granting the identified individual or system access to resources. An ACL (Access Control List) on a file folder is an example of an authorization mechanism. Authorization always typically happens after the user has been authenticated, however, it should include rights granted to or denied from anonymous users.
In application-terms, authorization is often referred to as role-based security.
Role = container for permissions (for example, a “Contributor” has rights to read, write and delete a record in a table)
Group = container for user accounts (for example, “Human Resources Group” contains all users in the HR department)
Authorization best practice = Associate Groups with Roles.
Resource Access Pattern
An application that accesses secured external resources, such as databases, a file shares, external web services or software systems, typically uses one of two high-level patterns to present security claims:
Delegation
The process of propagating a security identity from a caller to the resource. Delegation requires access to the user's full set of credentials (Impersonation). If the destination system does not accept the same type of credentials as the authenticating system, a Single Sign-On (SSO) intermediary can be used (see below). Delegation requires the user to have permissions to access the destination system.
Trusted Subsystem
This is a process where a trusted business identity (a "service account") is used to access a resource on behalf of the client. In this model, the user does not need to have direct permissions to the destination system, and no SSO solutions are required.
An example of a Trusted Subsystem is an ASP.NET / IIS web application running on Windows Server 2003, that will use the configured Application Pool Identity account to access a SQL Server database, if Impersonation is disabled (default) in the web.config, and the connection string specifies SSPI (Windows) authentication. This is the most commonly used scenario for database access.
To switch to a Delegation model, turn on Impersonation in the web.config. In this case the user identity will be passed to the database. If, however, IIS is set to allow Anonymous, that user identity will be the Anonymous user account configured on the web application. So take care with Impersonation!
Single Sign-On
Since it is not always possible to have one central credential store that is used by all enterprise systems, Single Sign-On (SSO) is used to work around the need for a user to remember multiple different credentials in order to authenticate with different systems. SSO enables the user to authenticate once and gain access to multiple systems in real-time. Portals, mash-ups and messaging systems are often the brokers for SSO solutions. All participating systems typically retain their credential stores.
Different methods for SSO exist, some require modification of source systems, others don’t. Enterprise SSO solutions involve a credential mapping process and secure storage of user’s credentials for participating systems as it relates to a central logon. Participating systems do not require modifications in order to support Ent SSO. This is sometimes referred to as “assembled identity”. Alternatively, real-time SSO can be achieved with Identity Federation solutions.
It makes sense that Enterprise Single Sign-On solutions would be part of messaging platforms (BizTalk Server 2006) and portal systems (SharePoint Server 2007), but I still have a hard time understanding why Microsoft does not offer a standalone EntSSO solution. Both products above started with the same EntSSO code-base, which have since branched and are independent.
Federated Identity
The term Federated Identity refers to infrastructure that does not attempt to unify credential stores (usually across organizational boundaries), nor does it attempt to provide central credential mapping services. Federation of authentication and authorization is achieved through contracted mutual trust. It is easiest to explain Identity Federation in an example:
Brian, an employee of Contoso Ltd. wants to purchase goods at a Fabrikam’s shop service. The employee privacy policy of Contoso Ltd. does not permit that PII (personal identifiable information) from employees is exposed to an outside partner such as the other company. It also would be an administrative burden to make all identities of authorized employees from Contoso available to the shop and to keep that list up to date. Additionally, the employee’s identity inside Contoso will probably be meaningless to the Fabrikam shop, because the shop is in another trust domain.
The solution is to have WS-Trust exchanging existing security tokens into different ones that are understood by the other party:
The employee’s shopping application sends a SecurityTokenRequest message to Consoto’s Security Token Service (STS), requesting a SAML token that will be accepted at Fabrikam (Step 1): “I am employee Brian from our IT department and I have to invoke the Fabrikam shop web service at this and that address.” The claim “I am employee Brian” is proved, for instance by signing that request message with the employee’s private key or by attaching a valid Kerberos token from Contoso to the message. After internal checks (such as “Is our employee Brian authorized to buy at Fabrikam’s shop of behalf of Contoso?”), the STS from Contoso sends back a security token to Brian (Step 2). That security token may include two things: It must include (a) a security token that Brian can attach to the web services invocation and it may include (b) a proof token for Brian with which he can prove that he possesses the security token. The security token may state that “The entity possessing this or that cryptographic key is an employee of Contoso and may purchase goods on our behalf”. This security token is attached to the shop message (Step 3). ‘Attached’ means that the shopping request is signed with the token. The shop’s web service cannot interpret the semantics of the token, and asks the Fabrikam’s STS to validate the token (step 4). The STS from Fabrikam may return a new security token containing information like: “The owner of this or that cryptographic key is employee of one of our gold customers” (Step 5). After checking that the message from step 3 is signed with the specified cryptographic key and that the security token from step 5 contains a claim that access is granted, the shop request is executed and the results are sent back to the customer (Step 6).
Standard protocols, such as WS-Trust, WS-Federation and SAML tokens are in development supporting the process of identity federation across different software vendors. Microsoft’s Active Directory Federation Services provide the infrastructure to supply STS services, as well as standard protocol and token support.
Applications and services need to explicitly support a Federated Identity model, i.e., require modifications to authentication and authorization modules.A framework for this is in the works from Micrsooft that enables integration of claims-based identity and authentication into .NET applications. It's code-named Zermatt and available as a Beta download.
Identity Selector
Identity Selectors are client applications that enable users to provide their digital identity to online services in a secure and trusted way. They shortcut Federated Identity scenarios by giving the User control over which identity to present.
Windows CardSpace (previously code-named InfoCard) is an example of an Identity Selector. It is what is known as an identity selector: when a user needs to authenticate to a web site or a web service, CardSpace pops up a special security-hardened UI with a set of “information cards” for the user to choose from.
Each card has some identity data associated with it – though this is not actually stored in the card – that has either been given to the user by an identity provider such as their bank, employer or government or created by the user themselves. The CardSpace architecture – consisting of subjects, identity providers and relying parties – is called “The Identity Metasystem”, a shared vision across the industry as to how we can solve some of the fundamental identity challenges on the Internet today.
An application or service must be capable to explicitly support Information Card sign-in.
Identity Lifecycle Management
Identity Lifecycle Management is the process of managing and automating the process of managing accounts and user identities throughout its appropriate life-time. The goals of such an infrastructure are to
- improve productivity of repetitive tasks
- reduce the security risk of failing to complete these tasks (such as de-provisioning of employee accounts when they leave)
- provide audit trails on identity change events
- reduce TCO associated with managing and integrating identity information across the enterprise.
Services provided by Identity Lifecycle Management tools should include at a minimum:
- Provisioning and de-provisioning of accounts across systems and platforms in heterogeneous security environments.
- Ongoing synchronization of identity information across various directory and non-directory identity stores (such as HR systems).
- Password synchronization and re-set, allowing the user or IT representatives to centrally manage all passwords across multiple systems.
Microsoft Identity Integration Server (MIIS) is a centralized service that stores and integrates identity information for organizations with multiple directories. The goal of MIIS 2003 is to provide organizations with a unified view of all known identity information about users, applications, and network resources.