You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

  • privileges, a generic model
    • group, role and role hierarchies, draft proposal for MACE-wide model and definition
      • Are the definitions in the glossary good enough or are their others that are more widely accepted?
        • mace documents ( grouper)  vs other standards groups
  •  

Groups/roles vs privileges

Applications have various access control needs to control which subjects have access to what.  This is generally for applications which require authentication, though the authorization could also apply to anonymous subjects (who would get privileges from an anonymous role).  There are several decisions for access control for applications including:  groups vs roles, roles vs privileges vs hybrid, hard-coded privileges vs external privileges vs centralized privileges.

When applications protect resources by checking if the authenticated user is in a group, they are implicitly making a virtual role from the group.  For example, if the application code checks if the authenticated user is in the institution's "student" group, in order for them to see the main screen of the application, then there is an implicit hard-coded privilege resource of "main-screen", and action "view", assigned to the role "studentUser", which is assigned to the group "student".  Though it is referred to as security by group, it is actually a role.

Generally an application will have a handful or up to a couple of dozen roles.  These roles are generally mapped to job function or affiliation.  For example there could be roles for student, staff, instructor, admin, billingAdmin, anonymousUser, etc.  Note that set of roles varies across applications as needed.  Roles are used as a security template that multiple subjects can be assigned to for common access.

If not all subjects in a role have the exact same access, then they need personalized privileges assigned to them.  The authorization system might assign privileges directly to the subject, or in the context of an application, or in the context of a role.  Either way, the subject will have privileges that are different from other subject in their role.  An example is to specify which data-sets the subject has access to when searching for data or running reports. 

If there is no access control framework or central system, then hard-coding the privileges in the application might be the easiest way to code an application.  An external privilege management system separated the privilege resources from the code, but still runs in the same application for that application.  A central authorization system maintains the roles and privileges in a central location as middleware for multiple applications.

    • Using groups and roles vs privileges, how to choose,  simple access management, centralized vs distributed.  Note: you can mix and match between these strategies in one application
      • You can centralize your groups/roles/privileges to take advantage of shared middleware, or to be able to centrally query/change authorizations, or to reuse the authorization settings across multiple applications
      • If you are hardcoding privileges in applications based on group, then you can have groups that hold the subjects allowed to do those things.  For example, you might have a group of timesheetUsers, and a group of timesheetAdmins, and in the application in the code you can see if the user is a timesheetAdmin and allow more features for that user
      • If you want to dynamically assign what a group is allowed to do, then you should use a role, externalize the privilege resources from the code, and assign those privilege resources to the role.  This role can be assigned to individual users or to groups of users.  Role based access control is useful in parts of your application where groups of users have the same privileges.
      • For parts of your application where users' privileges do not generally overlap with other users' privileges, you can assign privileges directly to the user
    • How much can access management be centralized vs embedded in applications?
    • Follow the attributes
    • Are there really use cases when access requires realtime evaluation or is static evaluation or cached evaluations enough?
      • Use cases using "presence detection" , is this person physically in a building  or a room
      • Use cases with quota evaluation, metering or rate limiting a for fee service?
    • case studies
  • attribute delivery recipe:
    • SAML between IdP & SP
    • SPML, XMPP ( grouper) for push provisioning
      • XMPP is a messaging protocol that many institutions already run with known security and addressing standards
        • JMS or activeMQ ? AMQP as a wire protocol.
    • LDAP , privilege registry or webservice   for pull provisioning
      • is there existing mace-dir work to build on?
  • generalizing to federated scenarios and VOs
    • What is the namespace  ( URIs vs  URNs) and object characteristics for privileges
      • what are the special problems in namespace choice?
        • The name/meaning of a privilege may reflect the policy intention of an organization or a virtual organization and may be applied to subset of either.
        • Some architectures take the "CRUD" view where everything is mapped to create, read, update, delete on specific objects
        • Some architectures use privilege names scoped to the  resources they reference.
        • examples
        • The actual privilege may be represented differently by the policy enforcement points in an application or service or may be represented in multiple application for services
        •  
      • Fifer using URIs  e.g. group://prodGrouper.upenn.edu/penn/apps/directory/users would specify a group so would a privlege be
        • privilege://accessmanager.andrew.cmu.edu/apps/s3/fields/ssn/read be the equivalent?
  • authorization and access control
    **case studies in production
  • rule-based access control
  • policy, a generic model
    • P*P architectures: proposed models,
      • Application policy, enterprise policy, VO policy
    • case studies - bamboo
  • Examples of access management in production
    • performance issues and design tradeoffs
    • Experience with commercial and open source offerings
    • The Aegis Identity Management Suite based on open standards tools
  • Delegation
  • No labels