Survey of Identity Repository Security Models JSR 351, Sep 2012

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

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

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

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

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

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

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

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?

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?