OGC Testbed-16: Federated Security

Figure 4 shows the architecture defined in Figure 2 cast into a data flow diagram. This diagram identifies all actors and interactions when a Federation Member authenticates to a Federation Service using OIDC.

Following the configuration shown in Figure 2, the Federation Service is shown behind the Fed Service Trust Boundary, along with the OIDC Server, Fed State, and the Fed Operator. A Member (and their browser) and a Service are shown behind their own Trust Boundaries. All dashed items are considered to be out-of-scope for the analysis documented in this ER. The Service, the Service Request and Response arrows are shown as out-of-scope since they are not involved in the authentication process. All other dashed actors and interactions are considered to be secure because they are behind the Fed Service Trust Boundary.

While this assumption may be flawed, it is based on currently established and accepted security practices, such as "securing" service endpoints by operating them on a different, internal subnet. Newer architectural approaches that do not require such assumptions are reviewed in Emerging Security Technologies.

As per the OIDC specification, the numbered arrows indicate the OIDC Authorization Grant Flow, the primary flow used by most applications to achieve authentication. (While this flow is called authorization, the first step is to establish identity, i.e., authentication.) When a Member asks to be authenticated (1), the Fed Service redirects the request (2) to the OIDC Server. The OIDC Server challenges the Member to authenticate (3) which the Member responds to (4). On success, the OIDC Server redirects back to the Fed Service (5) with a short-lived Authorization Code and a "state" value. The Fed Service uses this code to request an Access Token from the OIDC Server (6). The Access Token and ID Token are returned (7). These are JSON Web Tokens (JWTs). JWT is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object (jwt.io). The Access Token can be used to request further information about the Member (8 and 9). Finally, the results of the authentication are returned to the Member (10).

There are two very important security aspects to this protocol. First, the Member does not divulge any secrets to the Fed Service. That is to say, the Member authenticates directly with OIDC. This could be simply by using account name and password, multi-factor authentication, biometrics, or other methods. Second, no tokens or other credentials are divulged to the Member. The Access and ID Tokens are exchanged directly between OIDC and the Fed Service. By having OIDC act as a trusted, third-party, the Member and Fed Service do not have to directly exchange any secret information.

A threat analysis of this protocol is not trivial. However, an extensive threat analysis has been performed for OAuth 2.0 [26]. Since OIDC is essentially an integration of OpenID and OAuth 2.0, this threat analysis can be applied here. Threats and mitigations identified in [26] are cited as such in the Threat Dragon report.

Threat Analysis Summary and Discussion:

The analysis described focuses solely on those actors that have externally accessible endpoints and the interactions between them. That is to say, this analysis focuses on interactions that cross trust boundaries. For the purposes of this analysis, the endpoints and interactions that are completely behind a trust boundary, i.e. within a trust zone, are considered to be secure.

Also, while some Denial of Service (DoS) attacks are considered here, DoS attacks against the communication bandwidth between a Member and any part of the Fed Service are considered out-of-scope. There is nothing federation-specific about such attacks. Such attacks can be mitigated without requiring any structural or behavioral changes to a Fed Service.

With these ground rules in mind, the threat analysis recommendations can be summarized as follows:

While very insightful, these threats and mitigations emphasize the fact that such analyses must be done by individuals that have a first-hand knowledge and understanding of how RESTful web services are built and how they work. For example, understanding the Cross Site Request Forgery vulnerability means knowing exactly how the redirection protocol works, and more importantly, how the protocol could be misused. Also, a threat analysis for any system should be done against specific implementations. Different implementations of the same standard could have different vulnerabilities. For example, under extreme malicious loading conditions, a service may commit a synchronization error that allows a response to be returned to the wrong requestor. For all these reasons, any serious analysis to identify threats and effective mitigations must be done for a specific implementation and deployment, staffed by knowledgeable persons, and properly funded.

In this scenario, a federation Member has already been authenticated to the Fed Service. As illustrated in Figure 5, Members are being considered that are FedAdmins and ResOwners as they perform administrative functions. Only the Member Browser and the Federation Service are involved with a single pair of request and response interactions. This threat analysis applies to both FedAdmins and ResOwners since the threat model is structurally the same. A FedAdmin makes requests to the FedService to manage a federation’s members, e.g., to grant or revoke authorization attributes. A ResOwner makes requests to register service endpoints and manage the associated discovery and access policies.

Threat Analysis Summary and Discussion:

This threat scenario is clearly much simpler than the authentication process. Since the members are already authenticated, the enables the FedService to associate the member with a trusted set of authorization attributes. Aside from mitigating possible DoS attacks on either the Member or the Fed Service, the key security goal is to mutually secure the communications between them, e.g., to use mTLS. While this is an entirely reasonable approach, the next question is what are the threat vulnerabilities of TLS and mTLS? This is discussed in Threat Analysis Observations.

In Figure 6, members that are general Users are considered. Again, these Users have already been authenticated to the Fed Service for a specific federation.

General members can perform two functions: (1) query the federation’s Service Catalog, and (2) invoke a Service. A federation’s Service Catalog is maintained by the Fed Service. In response to a query, the Fed Service first applies the discovery policies defined by the ResOwners. The Fed Service then replies with a set of service metadata that (a) the User is authorized to discover and invoke, and (b) meets the User’s query parameters.

The User can then invoke one of these services. In this deployment model, the Fed Service proxies the call thereby allowing the Fed Service to apply the Service’s access policy. Upon granting access, the request is sent to the Service. The Service processes the request and sends a response which is forwarded to the User.

Threat Analysis Summary and Discussion:

Threats to the interactions between general Users and the FedService are essentially the same as they are for FedAdmins and ResOwners. In this threat analysis, however, Services finally come into the picture. Services never ask the Fed Service for anything. Services simply respond to requests. As before, while DoS attacks are possible and can be mitigated, the key security goal is to mutually secure the communications between the Service and the Fed Service.

The previous three threat scenarios have all dealt with a single Federation Service and its interactions with Members and Services. Figure 7 presents a final scenario that illustrates the interactions between two Federation Services.

As noted, each Fed Service can make requests to the other. As before, doing this securely depends on securing the communication channel. Fed Services do not authenticate to each other in the same way that Members authenticate to a specific federation. However, there does have to be a trust relationship between them, as part of the trust relationship between the organizations involved. Once this trust relationship has been established, the Fed Service Operators can configure their respective Fed Services to accept a connection from each other.

Threat Analysis Summary and Discussion:

As part of this simple deployment model, the identity of the Fed Services involved is being established out-of-band. Aside from mitigating possible DoS attacks, as before, the key security goal is to mutually secure the communication link between the two Fed Services.

Identity proofing is the process of verifying who a subject or applicant is when first establishing them as a valid subscriber in an identity system. To be more concrete, this is when a Credential Service Provider (CSP) associates an applicant with a digital identity that is documented with one or more digital credentials.

The NIST Digital Identities Guidelines [4] defines three Identity Assurance Levels:

These Identity Assurance Levels can all be applied in federated systems.

When authenticating a user or claimant, the claimant must demonstrate that they possess and control one or more authenticators, such as a username, credential, token, etc., that are used to prove their identity. The use of a single authenticator, such as account name and password, has been common for decades. However, stronger security can be achieved by using multiple authenticators in conjunction, such as Multi-Factor Authentication (MFA).

Authenticators can be broadly categorized into:

A common MFA approach uses account name and passcode, in conjunction with an RSA fob that presents a PIN code with limited time validity, for example 60 seconds.

The NIST Digital Identities Guidelines [4] defines the following Authenticator Assurance Levels:

While all of these authentication methods and Authenticator Assurance Levels can be applied in federated environments, federation raises the additional possibility of federated identity management. Federated identity entails the ability of a user to use identity credentials issued by an Identity Provider (IdP) in one domain to access resources in another domain. Doing this, however, depends on credential management and trust. This leads to the next discussion topic.

Managing the use of credentials across identity domains, and the identity attributes that might be carried on them, i.e., released, is a significant issue in federation. To give some structure to this issue, the NIST Digital Identity Guidelines [4] define three Federation Assurance Levels. These refer to the strength of an identity assertion issued by an Identity Provider (IdP) in a federated environment when communicating that information to a Relying Party (RP):

While these assurance levels are useful, the added dimension of federation that must be emphasized is that the RP and IdP will be in different identity domains.

A key function of a federated environment is to enable an RP in one domain to trust and understand the credentials issued by an IdP in another domain. The RP must trust that the credential:

Once this trust is established, the RP must have a common understanding about what the identity attributes mean, such as how they can be used to evaluate an access policy and make a valid access decision. A fourth requirement can be added from the User’s perspective:

Item (a) above requires a credential belongs to a user. Please note, however, FAL1 is based on the concept of a bearer assertion. This is something the user or subscriber (the bearer) presents to the Relying Party as sufficient proof of identity. Bearer assertions, or bearer tokens, are vulnerable to man-in-the-middle or snooping attacks, and simple device theft. If an attacker acquires a bearer token, by any means, they attain all the rights of the legitimate user.

The need to avoid the limited security offered by bearer tokens and achieve the three trust requirements described above has motivated the development of various security architectures, such as Public Key Infrastructure (PKI) [28]. PKI utilizes a Certificate Authority that issues signed and encrypted certificates that are only valid for the intended subject. PKI is widely used with the established X.509 certificate format [29]. When a User requests service and presents a certificate, the RP can verify the certificate with the Certificate Authority. Importantly, this type of approach also addresses Items (b) and (c).

While PKI is widely used and considered quite secure, another design concept that increases security even further is to not divulge credentials directly to the user at all. PKI certificates can be directly installed on a user’s browser or device. As discussed in A Threat Analysis of Authentication to a Federation Service, OpenID Connect (OIDC) [30] avoids doing this. When a User requests service from an RP, the RP can redirect the User to authenticate directly to an OIDC Provider (OP). On successful authentication, the User is redirected back to the RP with an authorization code. The RP uses this code to get an ID Token and Access Token directly from the OP. The User never sees their ID and Access Tokens, and has no control over them.

This architectural approach for OIDC, however, was actually developed to support Federated Identity Management (FIM). On the surface, the goal of FIM is to enable a User A from Organization A to access resources at Organization B using their identity credentials from Organization A. However, the market-driven usage scenarios that motivated this, however, were quite limited in scope. One example is enabling a User’s Facebook account to access photographs on the User’s Snapchat account. This does require that Snapchat trusts the User’s IdP and having the User authenticate to approve the access by Facebook.

While there is certainly a mass-market use of federated identities, it is far from a general federation capability. First, it assumes that a User knows about and can invoke any service that is available on the Internet. There is no notion of a Service Owner being able to manage the discovery of their services through policy. The Service Owner must determine where the User is coming from, and who is the User’s IdP. The Service Owner must then determine if they know and trust the IdP. Usually this means that Service Owner must maintain a list of IdPs that they trust. When making a service request, the User must select an IdP from the Service Provider’s approved list — which hopefully includes the User’s IdP. Even when this is done, there is no guarantee that the User’s IdP can provide the attributes necessary for the Service Owner to make an access decision. This may be because the IdP does not know or understand what type of attributes are being requested, or because the IdP does not wish to release those attributes for some organizational reasons. For all of these reasons, simple FIM is insufficient for managing general federations.

The NIST CFRA addresses all these issues by enabling "purpose built" federations to be defined and instantiated. By considering a federation to be a virtual administrative domain, it is possible to manage membership in a federation, along with the roles, attributes and policies necessary to manage its operation. That is to say, defining the "rules of the road" for members and establishing an expectation of what it means to be a member in good standing is possible. There is no question about what the roles and attributes mean, or how they are used by the federation’s service owners. What the NIST CFRA does is provide a scoping mechanism whereby existing authentication and authorization tools can be leveraged to instantiate any number of federation instances. These instances can be independently managed according to their own governance requirements.

The issue of attribute release — Item (d) above — has already been mentioned several times. This is a significant issue for many existing federation systems and is examined here in more depth.

While thinking of a credential as documenting everything there is to know about a User is easy, an RP may only need one or two attributes to make a decision. Aside from not sending extraneous information, there may be attributes that a User (or their organization’s IdP) may not want to divulge to an RP that does not need to know. In a single domain, attribute release is less of a problem since information is "all within the family", i.e., the same trust domain. In a federated environment, however, attribute release becomes more of an issue and must be explicitly managed.

When an organization is must managing their own environment, the attributes used and how they are encoded into credentials is typically not an issue. However, if such an organization — or some subset of their users — later wishes to federate with another organization for any purpose, their IT security architecture was probably not designed with this use case in mind. From an organizational governance perspective, they may have been unprepared to share identity attributes with other organizations, of rather, undecided about how to do so. Organizational IdP administrators may be faced with competing requirements concerning how to expose attributes to external RPs. The only tractable solution for many administrators will be to release nothing.

The NIST CFRA avoids this problem by defining a virtual administrative domain where attribute release is simply not a problem. The goals and purpose of a federation are well-defined. Hence, the attributes and how they are used are well-defined. The necessary attributes to make discovery and access decisions are well-defined. This means their release can also be well-defined.

There are, however, other ways of addressing the attribute release issue that could also be used in federated environments. The approach taken by W3C Verifiable Credentials [13] enables the user to directly control their credentials and how attributes are released. This design approach is illustrated in Figure 8.

While Issuers (IdPs) continue to issue credentials to Holders (Users), the Holder maintains all of their credentials in a repository that can be called a wallet (not illustrated). Credentials are only valid for a specific subject, which may the Holder but could be another entity associated with the Holder. When requesting service from a Verifier (Relying Party), the Holder creates a custom credential presentation built from any of the credentials in their wallet. Hence, the Holder has complete control over their attribute release when interacting with Service Providers. The credentials and presentations are constructed and signed such that they can be verified through a Verifiable Data Registry. Hence, Verifiable Credentials are not bearer tokens, even though they can be used as bearer tokens by leaving the subject field in a credential presentation empty.

Verifiable Credentials (VCs) handle credentials in a way that is very different from third-party IdPs. VCs were deliberately patterned to work the same way as physical credentials. A typical person will have a wallet with physical credentials, such as a Driver’s License, credit cards, auto club card and so forth that can be presented for identification and receive services. Of course, all this depends on a set of public Issuers that can be consulted to verify credentials. Hence, VCs are a close parallel to how humans go about their business right now. For this simple reason, VCs might gain market adoption in the coming years.

However, this design approach also makes it difficult for controlling how a user may use their credentials in subsequent presentations. For many application domains, after granting a credential, the Credential Issuer may wish to stipulate that the User may only use the credential in presentations to entities on an approved "white list", and must never use them in presentations to entities on a "black list". Such requirements are not known to be handled at this time.

The VC approach to credential management is actually quite compatible with the NIST CFRA approach to federations. A fundamental tenet of the CFRA model is that a federation is a virtual administrative domain whose governance should be defined and agreed upon by the potential members prior to instantiation. That is to say, the policies used to manage resource discovery and access are defined over a set of common, well-known attributes. In the VC case, these attributes can be provided by public issuers. The members simply need to agree on the Issuers and attributes to be used. A Federation Service, however, will still need to maintain a service catalog for each federation whereby discovery policies can be enforced. Likewise, some form of Policy Decision Points and Policy Enforcement Points would have to be used whereby access policies can be enforced.

These architectural concerns for managing identity, credentials, and the attributes they carry, are certainly important. However, these mechanisms must be deployed in conjunction with trust and understanding, i.e., semantic interoperability.

Trust can be broadly categorized in a hierarchy [32]:

The bottom two layers in this hierarchy can be termed computational trust. For most systems, establishing computational trust means that a set of requirements have been satisfied. Depending on the use case scenario and the stakeholders' risk tolerance, that necessary set of requirements will vary. In any case, trust can be said to be a binary, yes/no decision. (While reputation systems have been devised to manage varying degrees of trust, these are out of scope for this engineering report.) This ER chapter explores what trust requirements may be for federated systems and how they can be realized.

The hierarchy above can be further refined into the concept of trust models [33]. Linn, et al., define the notions of Business Anchor and Trust Anchor. A business anchor "represents an entity with which its holder has a direct business relationship." That is to say, some type of business agreement has already been established between two human organizations. A trust anchor "represents an entity and key that the anchor’s holder has determined to trust directly for cryptographic authentication purposes." This allows two organizations "connected" by a business agreement to establish trusted electronic communications based on cryptographic methods. Human organizations can maintain Business Anchor Lists and Trust Anchor Lists whereby sets of trust relationships can be managed. Based on these concepts, trust models can be categorized as follows:

In practical scenarios, these trust models need to be managed in the context of a trust framework. This is especially true for brokered/transitive trust and community trust where establishing paths of trust chains or community trust requirements must be managed.

To this end, Temoshok and Abruzzi present a guide for developing trust frameworks for identity federations [11]. While focusing on identity federations, this guide is directly relevant to general federations, as defined by the NIST CFRA. As the basis of authentication, this work takes the approach of OIDC (as illustrated in the Threat Dragon models). When a User requests service from a Relying Party, a pair of redirections is used whereby the User authenticates to the IdP, and the IdP provides the authentication status directly to the RP. The NIST CFRA augments such identity federation by integrating it with resource federation. That is to say, the resources in a federation are managed according to discovery and access policies based on the identity roles and attributes that are well-known within a federation. Hence, this ER section extends the trust framework approach presented in [11] to general, CFRA-based federations.

NIST Trust Frameworks govern the interactions among three main actors:

A Trust Framework encompasses a set of rules governing how:

To accomplish this, a Trust Framework is comprised of four components:

In [11], these components are discussed specifically for identity federations. Their implications for general federations are now considered.

Trust is an immense subject. Trust frameworks and their approaches are an equally immense subject. There are, however, several tools and efforts being developed. These directly support the formal definition of general federations, their legal structure, and the establishment and evaluation of conformance. Such tools are necessary for creating secure and trustworthy federations.