Some tutorial slides on ABAC

transcript

D u k e S y s t e m s

Jeff ChaseDuke University

PrefaceThis slide deck has some introductory slides useful for understanding

role-based trust delegation logic: ABAC.

Its purpose is to lay some foundations for a longer series on how to use ABAC as a foundation for trust management in GENI.

See http://groups.geni.net/geni/attachment/wiki/AuthStoryBoard/

IdP.facultyD

Reading the slides

IdP.studentT

GENI users Test Tube Guy and Dr. D, and some of their credentials

A coordination service implementing some clearinghouse function, such as a Slice Authority

Indicates trust of one principal in another, often associated with some kind of formal agreement:

Indicates a request

Indicates credential flow

A A generic principal

AMAggregate

Basic concepts

• A principal is any entity that may:– Request an action

– Respond to a request

– Assert or receive a statement

– Know a secret

• Trust is that which a principal must have in order to:– Honor a request

– Accept a response

– Believe a statement

– Reveal a secret

trusts

Trust is usually limited to a particular function or purpose, which we would like to specify rigorously.

Trust graph

• Trust may derive from a trust path through one or more intermediate principals that endorse another party.

Client Server

• Each step in the trust path follows a delegation of trust from a principal to its successor in the path, specified by its policy.

• We would like to constrain each delegation and specify rigorously and exactly what trust is delegated.

Certificates and credentials

• Each principal has at least one keypair that it may use to issue signed assertions.– Assertions represent delegations, policies, name bindings.

• Any such signed assertion is a certificate or “cert”.– Certificates reference other principals by their public keys.

– A credential is a certificate used for authorization.

Given knowledge of a public key, it is easy to secure communication with the principal who is using that keypair (authentication).

We focus instead on authorization or trust management: how authenticated principals use credentials to establish trust.

CertificateTerm of validity

Issuer’s name (or key)

Signature

Payload: assertion

IEEE Symposium on Security and Privacy, 2002

http://abac.deterlab.net/

Entities and attributes• Entities (principals) have roles, powers, rights.

– These are represented as attributes.

– An entity may have multiple roles/attributes.

• Attributes of an entity are asserted by other entities.– Attributes are not permanent.

– Attributes are not inherent or absolute.

• Each actor has policy rules to infer belief in attributes, e.g., based on assertions made by other entities.– An actor bases decisions about trust and authorization on inferences

and beliefs about entities and their attributes.

– E.g., “Alice is the operator for server S” is an attribute of Alice accepted by S as a consequence of its local policy.

A simple example

Client E Server ARequestCommand c on Object o

Credentials representing policies

Credentials representing attributes + capabilities

Query A.coE?

ABACinference

engine

query context

To authorize the request, A gathers relevant credentials to “prove” it believes that entity E possesses an attribute co required to issue command c on object o.

Constrained delegation in ABAC

• A principal delegates trust to another by endorsing its public key for possession of an attribute or role.

• The delegation is limited to the powers conferred by that attribute or role.

• The delegation is written as a logic statement and issued in a credential.

trustsA B

A.trusts B Note that the arrows in ABAC syntax run “backwards” from the delegation: they indicate membership of one or more entities in a set associated with a given role.

ABAC: facts and rules

A.r {E}“A believes:” “These entities {E} have the role r.”

A.r (A.king).r“A says:” “If my king decrees E has role r,

then I accept it.”

These facts/rules are encoded in credentials signed by A.

Libabac uses X.509 as a transport: a convenient implementation choice.

ABAC in GENI

• ABAC is a powerful declarative representation that can capture the GENI authorization/trust model.

• It saves a lot of code, provides a rigorous foundation, and preserves flexibility for future innovation.

• It can be easy for users, with some new user tools for delegation.

• Declarative policies can evolve “easily”.

• Signed credentials introduce interesting new challenges for credential management.– But we can solve them with a distributed service for credential storage,

revocation, renewal: an early application of a networked cloud! We return to this topic later…

Aaron’s namespace of

Chip’s namespace

of roles

Each entity (principal) has its own namespace of roles (attributes).

Chip’s namespace

of roles

Each entity (principal) has its own namespace of roles (attributes).

Reader beware: the arrows in this sequence of ABAC tutorial slides follow the ABAC set membership flow: they run backwards from the

trust delegations!

Bob’s namespace

of roles

Chip’s namespace

of roles

Entities may issue credentials (certs) to assert facts and rules about who wields attributes in issuer’s namespace.

Bob’s namespace

of roles

Chip’s namespace

of roles

A.r1B.r2

A.r1 E

Type 1: Role definition credential

B.r2 E

Bob’s namespace

of roles

Chip’s namespace

of roles

A.r1 B.r2

Type 2: Linked delegation(Restricted delegation)

Bob’s namespace

of roles

Chip’s namespace

of roles

A.r1 B.r2

B.r2 E

Bob’s namespace

of roles

Chip’s namespace

of roles

A.r1 B.r2

A.r1 E(inferred)

B.r2 E

Bob’s namespace

of roles

Chip’s namespace

of roles

Example access policy:A.coB.r2

A.co B.r2

Bob’s namespace

of roles

Chip’s namespace

of roles

A.co B.r2

B.r2 E

Bob’s namespace

of roles

Chip’s namespace

of roles

EAccess granted.

A.co B.r2

B.r2 E

Bob’s namespace

of roles

Chip’s namespace

of roles

A.r1B.r2

Type 3: Attribute-based delegation

B.kCA.r1 (B.k).r3

Aaron’s worldview

Bob’s worldview

Chip’s worldview

A.rB.k

By convention, we may agree on a global namespace of roles.

Then ABAC facts become statements of belief by principals.

ABAC rules declare trust structure.

B.kCA.r (B.k).r

A.r B.r

A.r E B.r E

“Design patterns” for RT0

• The purpose of a declarative framework is to specify stuff declaratively, instead of in code.

• But the framework is too weak to say what we want.– We need global objects: slices and projects.

• Solution: sprinkle “just a little” code around RT0 to do what we want. Here’s a look ahead:– Global objects rooted in coordination services (SA, PA)

– Simple Object Definition Credentials for global objects

– Object Specific Roles (OSRs)

– Templated rules with fast, practical inference

– Support for global objects in server-side guards

Next question

Credential flow

What does it really mean?

Credential management

• Each principal possesses many certs.– Which ones are relevant to a given request? Where are they?

• Some of those certs are delegated.– Server needs even more certs to validate delegation chain.

– Those certs belong to someone else. Server gets them…how?

• Credentials expire.– How to automate renewal?

• People change…and people lose their keys.– Revocation: how to do it fast and make it stick?

– How to rebuild credentials with new keys?

– How to keep the system safe in the real world?

Cloud-based credential storage

• Concept: always-on, highly available credential store.

• The store is lightly trusted: it cannot forge credentials, but we must trust it not to “forget” them.

Server

Put issued credentials and policies (certs) in the store.

Get certs to“cache or check”.

Pass credentials by reference in request.

Cert Store

Some tutorial slides on ABAC

Documents