Access control in distributed systems

All distributed systems need mechanisms for securely transferring access requests, attributes, policies and decisions between nodes. These mechanisms rely largely on cryptography. Compared to centralised systems, the distributed system require more work. In particular, it must be possible to identify and retrieve all factors that influence the processing of a given request. This section discusses trust networks, i.e. federations, formed by multiple organisations. In such a system, policies set by one party are used in another party’s decisions.

Federated access control

When a distributed system is formed by cooperating organisations that trust each other, the overall access control system is often called federated identity and access management. In the basic situation of federated IAM, an employee of one organisation logs into the systems of another organisation that provides services to the employee’s organisation. Their own organisation manages the identity, and the other organisation relies on it in performing access control.

Federation brings efficiency benefits: the user needs fewer usernames and passwords, redundant user data requires less maintenance, and the time spent resetting passwords decreases. Additionally, for example, outsourcing organisational services becomes easier because new usernames and passwords need not be created for that purpose. Federated identity management particularly enables single sign-on (SSO): with the same authentication, the user can access multiple services.

When organisations form a federated access domain, identities with their many attributes, policies, and decisions must be brought from different contexts (namespaces). A federation may have several places where policy is handled: somewhere rules are set, somewhere access requests are decided, somewhere decisions are enforced, and somewhere additional information can be obtained for evaluating requests. (These four places were already introduced earlier.)

The basic components of federated identity management are:

• Identity Provider (IdP): A server that authenticates the user at login time. At the same time, the identity provider supplies the user’s attributes to the relying service.
• Relying Party (RP) or Service Provider (SP): A server that relies on the authentication performed by the identity provider and on the attributes received from it. The relying service is the “actual” application that requires user identification.

Federated identity management has many security benefits:

• The username and password never appear to the relying service, because they are given only to the identity provider. Thus, a breach of the relying service cannot result in the leaking of usernames and passwords.
• Because the user has only one username and password for logging into the identity provider, stricter quality requirements can be imposed on the password.
• If password authentication is to be replaced with stronger authentication, strong authentication can be enabled centrally in the identity provider. This gives all relying services access to strong authentication at once without requiring changes in the relying services.
• If user logins always occur through the central identity provider, traceability and reporting become easier. For example, if there is reason to suspect that a user account has been compromised, the identity provider’s logs can be used to determine which services the stolen identity has accessed.

One of the biggest challenges in federated identity management is trust between organisations. Trust refers to the extent to which a party is willing to rely on another party in a certain matter and feels relatively safe even though there is a possibility of negative consequences (cf. concept maps). The question of inter-organisational trust is crucial because the identity provider and the relying service are maintained by different organisations.

• The relying service must trust that the identity provider has identified the user sufficiently reliably. The required reliability depends on the relying service – the more sensitive the service, the more reliably the user must be identified.
• The relying service must trust that the attributes provided by the identity provider are correct and up to date. The access control decision may rely on the user’s attributes.
• The identity provider must trust that the relying service does not violate the user’s privacy when processing the attributes provided by the identity provider.

The parties must manage the risk that the counterpart is not worthy of the trust placed in it. A key way to manage risk is to agree on the rights and obligations that apply to federated identity management. The agreement includes not only technical matters (e.g. protocols, certificates, and attribute schemas) but also operational practices (e.g. requirements for authentication reliability, the timeliness of attribute updates, and service availability).

Question 1

Federated identity and access management

simplifies the organisation.

improves organisational efficiency from the viewpoint of managing usernames and passwords.

eliminates the need for trust between organisations.

probably has something to do with Star Trek.

Question 2

The identity provider

is usually outside the user’s home organisation.

is responsible for ensuring that the relying service handles user data correctly.

performs authentication according to the relying service’s requirements.

is responsible for reliably identifying the user and ensuring the correctness of the user’s attributes.

Question 3

The relying service

can leak usernames and passwords.

trusts the authentication performed by the identity provider.

receives user attributes from an attribute service.

maintains logs of which services the user has logged into.

Source:

• Linden, M. (2017). Identiteetin- ja pääsynhallinta. (Tampereen teknillinen yliopisto. Tietotekniikan laboratorio. Raportti; Vuosikerta 7). Tampere University of Technology.

Posting submission...