Identity Management and Access Control

Leading change across distributed IT service providers requires extensive engagement. Implementing identity and access management (IAM) changes requires involvement of a broad spectrum of constituents. Using techniques developed during ERP and other large-scale change initiatives, we engage the university community in developing requirements and architecture for successful IAM changes.

Successful IT infrastructures and architectures are expected to nimbly provide the context for protecting and sharing information and identities. In today's world, new legislation, expectations from faculty and students, and managing risk several times a second are all threats to keeping current services relevant and time to market for new services reasonable. Understanding the importance and nature of the intersection created by security, identity, and policy is vital to planning the future of our infrastructures and architectures.

This presentation discusses how California College of the Arts met the challenge of securing an evolving wireless network.

Enterprise authorization requires the management of group, role, and privilege information to ensure consistent access policy across applications. This session will compare and contrast how multiple institutions have implemented this infrastructure and offer an initial view into shared practices for access management.

All dozen institutions comprising the CIC recently decided to join the InCommon Federation. This session will describe the motivation for and experience of joining InCommon. We'll also describe some of the use cases, including interactions with the federal government, interinstitutional access, and community source development projects.

Brown University recently implemented MACE Grouper as an integral part of our identity management infrastructure. This presentation will outline the scope of the implementation, discusses lessons learned in the process, and present next steps for Brown's group management infrastructure.

A step up from using groups, role-based access control enables privileges to be assigned to institutional roles assigned to individuals. Even though this is the brass ring of access control, leading an initiative to define the policy and process guiding this infrastructure is daunting. Questions arise, such as who should be represented in the roles system? You may find you have more than one organizational chart, so which one do you use? Who should decide the roles structure and make the policy decisions? For which resources will you be assigning privileges? And will you list all the roles and their access rights or have the supervisors/area managers assign rights given a set of boundaries? The outcome of the former could be a list of exceptions, and the outcome of the latter could be a pattern that leads to a set of defaults, clustering around the distinct roles. But there is no one way. This panel will explore this complex issue and provide a number of perspectives on how to plan for such an effort.

A level of assurance (LoA) refers to the degree of certainty that (1) a resource owner has that a person's physical self has been adequately verified before credentials are issued by a registration authority, and (2) a user indeed owns the credentials they are subsequently presenting to access the resource. The requirements for the level of certainty at both ends of that set of transactions should be driven by a risk assessment based on the value of the resources being protected. This session will describe the concept of LoA, discuss its importance, outline its technical components, and discuss the proposition that roles of the identity management and security staff are critical for a successful implementation of LoA.

Personal privacy is about protecting individuals and them control over their personal information. Institutional privacy is about protecting proprietary information. In either case, privacy requirements must reflect campus values and also meet the institution's legal and regulatory obligations. The requirements must be reflected in the identity management system: its flexibility, how it is used to support access to resources, and who makes the decisions about that access. IAM can provide for the externalization and consolidation of roles that can be used to determine permissions and access without that function being built into each resource. This session will discuss these topics from the auditor, identity management architect, and security staff perspectives and offer a case study on how one campus has addressed these issues.

Provisioning access is an IAM function, and deprovisioning that access is a security objective. How might these combined objectives be met with common process, and what sorts of access should be managed by it? Data, applications, networked services, and physical facilities all have particular provisioning and deprovisioning needs. Campus cards, for instance, mitigate risk only when the access information associated with them is current. When a card's rights get out of sync with its bearer's status, the card itself becomes a risk. Addressing this issue, given all the authorization and access points, can be a challenge unless they are tied into the enterprise identity management system.