Survey of Identity Repository Security Models

1. Survey of Identity Repository Security Models JSR 351, Sep 2012

2. Background • JSR 351 Terms – Attribute Repository, Identity Repository, Attribute Service • This survey is limited to identity repositories only • JSR 351 scope of work includes a security model for the (Identity) Attribute Service • Includes access control model for the release of attributes • This area needs more definition and use-cases • Survey of two popular identity repositories • LDAP Directories • Facebook

3. Actors • User – entity on behalf-of-whom access to identity data is sought • No user, client is action on its own behalf • Present, client acts on behalf of user with active session • Absent, clients acts on behalf of user with no active user session • Client – application which interacts with the identity repository • Network protocol • LDAP protocol • Facebook Graph API (actually a REST network protocol) • Identity Repository

4. LDAP Security Model • Every entry in a LDAP directory has a distinguished name (DN) • Both leaf nodes and non-leaf nodes have DNs • Clients open connections to directories over server-side TLS/SSL • Clients perform a FIND and BIND operation to establish an authorization identity • Typically a DN • BIND operation may include credentials • Anonymous mode also supported

5. Proxy Authorization • Directories can be configured to allow clients to impersonate classes of users • “HR application can impersonate all users at employment level 6 or below” • Client authenticates to the directory and then selects a different authorization identity • No standard mechanism but all directories support some form of proxy auth • Policies can use filters based on DN and attributes to limit the class of impersonated users • Avoids the “su” problem

6. LDAP Authorization Model • No standard model • But draft-ietf-ldapext-acl-model-08.txt is helpful • Servers implement AuthZ model based on • Authorization identity • Target • Operation • Access Control Rules use patterns and search strings • Anyone can read entries in the “dc=oracle,dc=com”subtree, they can view all attributes except for pwd

7. AuthZ Model Continued • Sophisticated policies can be expressed • Delegated administration • Group membership • Roles or Attributes • Default deny vs. default access • Also a source of complexity • Different products use different models • Design and testing of policies requires expert knowledge and effort

8. Facebook • Based on documentation accessed Sep 2012 • Certain amount of information is available without client or user authentication • This is information that the user has declared public • Users can grant secured access to a client application • Based on Oauth 2.0 three-legged flow • Once authenticated, user gives consent for sharing • Clients may request permissions for varying access

9. Permissions • Map directly to Oauth 2.0 scope parameter • Categories • Basic (default – id, name, picture, gender, locale) • User and Friends Permissions (e.g., user_likes) • user_xxx (provides access to xxx data section) • friends_xxx • Extended Permissions • Enables administrative privileges • Open Graph Permissions, Page Permissions • For more advanced apps?

10. Facebook Summary • User-mediated access model has many strengths • But its hard to disentangle principles from Facebook specifics • How to discover permissions required for access to attributes? • Is the “user absent” case covered by long-lived Oauth access tokens?