1 / 28

Some tutorial slides on ABAC

Some tutorial slides on ABAC. Jeff Chase Duke University. Preface. This slide deck has some introductory slides useful for understanding role-based trust delegation logic: ABAC.

ziven
Download Presentation

Some tutorial slides on ABAC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Some tutorial slides on ABAC Jeff Chase Duke University

  2. Preface This 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/

  3. Reading the slides GENI users Test Tube Guy and Dr. D, and some of their credentials A A generic principal IdP.studentT IdP.facultyD A coordination service implementing some clearinghouse function, such as a Slice Authority AM SA Indicates trust of one principal in another, often associated with some kind of formal agreement: Indicates a request Aggregate Indicates credential flow

  4. 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 A A B trusts Trust is usually limited to a particular function or purpose, which we would like to specify rigorously.

  5. 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.

  6. 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. Certificate Term of validity Issuer’s name (or key) Payload: assertion Signature

  7. IEEE Symposium on Security and Privacy, 2002 http://abac.deterlab.net/

  8. 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.

  9. A simple example Credentials representing attributes + capabilities ABAC inference engine Credentials representing policies Client E Server A query context Request Command c on Object o Query A.coE? • To authorize the request, A gathers relevant credentials to “prove” it believes that entity E possesses an attribute corequired to issue command c on object o.

  10. 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. 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. A.trusts B A B trusts

  11. ABAC: facts and rules A.r  {E} “A believes:” “These entities {E} have the role r.” A.r  (A.king).r “If my king decrees E has role r, then I accept it.” “A says:” These facts/rules are encoded in credentials signed by A. • Libabac uses X.509 as a transport: a convenient implementation choice.

  12. 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…

  13. Aaron’s namespace of roles Each entity (principal) has its own namespace of roles (attributes). Chip’s namespace of roles

  14. Aaron’s namespace of roles Reader beware: the arrows in this sequence of ABAC tutorial slides follow the ABAC set membership flow: they run backwards from the trust delegations! Each entity (principal) has its own namespace of roles (attributes). Chip’s namespace of roles

  15. Bob’s namespace of roles Aaron’s namespace of roles Entities may issue credentials (certs) to assert facts and rules about who wields attributes in issuer’s namespace. Chip’s namespace of roles

  16. Bob’s namespace of roles Aaron’s namespace of roles B.r2 A.r1 A.r1  E B.r2  E E Type 1: Role definition credential Chip’s namespace of roles

  17. Bob’s namespace of roles Aaron’s namespace of roles A.r1  B.r2 B.r2 A.r1 Type 2: Linked delegation (Restricted delegation) Chip’s namespace of roles

  18. Bob’s namespace of roles Aaron’s namespace of roles A.r1  B.r2 B.r2 A.r1 B.r2  E E Type 2: Linked delegation (Restricted delegation) Chip’s namespace of roles

  19. Bob’s namespace of roles Aaron’s namespace of roles A.r1  B.r2 B.r2 A.r1 A.r1  E (inferred) B.r2  E E Type 2: Linked delegation (Restricted delegation) Chip’s namespace of roles

  20. Bob’s namespace of roles Aaron’s namespace of roles A.co B.r2 B.r2 A.co Example access policy: A.coB.r2 Chip’s namespace of roles

  21. Bob’s namespace of roles Aaron’s namespace of roles A.co B.r2 B.r2 A.r1 B.r2  E E Example access policy: A.coB.r2 Chip’s namespace of roles

  22. Bob’s namespace of roles Aaron’s namespace of roles A.co B.r2 B.r2 A.r1 B.r2  E E Access granted. Example access policy: A.coB.r2 Chip’s namespace of roles

  23. Bob’s namespace of roles Aaron’s namespace of roles B.r2 A.r1 B.kC A.r1  (B.k).r3 C.r3 Type 3: Attribute-based delegation C Chip’s namespace of roles B.k

  24. Aaron’s worldview Bob’s worldview A.r  B.r B.r2 A.r A.r  E B.r  E E B.kC A.r  (B.k).r C.r 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. Chip’s worldview B.k

  25. “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

  26. Next questionCredential flow What does it really mean?

  27. 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?

  28. 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. Put issued credentials and policies (certs) in the store. Cert Store Get certs to “cache or check”. Pass credentials by reference in request. Server See also: Conchord, CERTDIST

More Related