Please report any problems to the Shared Tools Team at st-help@doit.wisc.edu    Broken Links? Missing Macros? WIKI Retiring Plugins
Child pages
  • IAM Guiding Principles
Skip to end of metadata
Go to start of metadata

Identity and Access Management (IAM)Principles

Definition

Principles represent the highest level of guidance for IT planning and decision making.  Principles are simple statements of an organization's beliefs about how it wants to use identity and directory services over the long term, and are derived from business goals and corporate values. (Burton Group)

Common Good

Principle: Deliver the most good to the broadest range of campus users.

Rationale: A critical success factor for IAM is the timely delivery of new and enhanced services to campus as well as the willingness of campus users to adopt those services.

Implications: Minor cases with minimal additional cost in time and resources are included in the solution. If a minor case cannot be addressed cost effectively, the case is separated from the major cases and addressed at a later date.

People and Process Focus

Principle: Support administrative, education and research processes and people.

Rationale: Higher adoption of IAM services provides greater benefit to all campus and UW-System customers. Adoption rates will be higher if the IAM system is process focused and easy to implement and use.

Implications: Campus and/or system representatives are engaged in all phases of development and implementation attending to usability and ease of adoption.

Policy Compliance

Principle: Comply with UW Madison and UW System IAM and security related policies.

Rationale: An important goal of the IAM implementation is to support compliance with UW Madison and UW System policies related to IAM and security, especially the protection of sensitive data.

Implications: Policy compliance is considered when deploying new or modifying existing services. The project teams assist campus users to comply. Instances of non-compliance are referred to UW Madison IT Security, Internal Audit, IMLG (Identity Management Leadership Group) and/or the UW System IAM Steering Committee as appropriate. Where the lack of a formal policy creates uncertainty as to how a service should be deployed, an issue is created and referred to the appropriate governing body for resolution. IAM services are not implemented so as to informally define policy (i.e. technologists do not approve IAM or security policy).

Identity Data Custodianship

Principle: Identify data custodians for identity data.

Rationale: Identifying and involving data owners and stewards in the evolution of services is critical to ensuring the integrity and appropriate use of identity data.

Implications: Data custodians and stewards are involved in the design and deployment of any services that use identity data. Questions regarding data custodianship or stewardship are referred to the appropriate governance group. Data custodians and stewards are documented.

Commitment to Higher Education

Principle: Support higher education institutions and standards where feasible.

Rationale: A high level of collaboration between campus, UW-System and other higher education institutions is becoming increasingly important to achieving our education and research missions.

Implications: Focus on the need to collaborate with external parties as plans are developed. Look for opportunities to leverage what already exists (e.g. the InCommon federation) to support integration and deliver solutions faster.

Delivering Business Value

Principle: Deliver business value in functional iterations.

Rationale: Iterative delivery implements a subset of the requirements and iteratively enhances the evolving sequence of versions with new functional capabilities until the full system is implemented. This approach allows for frequent delivery and demonstrates visible progress. There is clearer alignment of functionality with business priorities by delivering what the business has prioritized as the greatest value.

Implications: Functionality is divided into well-scoped time-based iterations. What is learned in development and use of previous iterations helps drive and define the next iteration. Every piece of work does not have to be completely understood and defined up front. Iterative roll-out of functionality may mean sub-groups of stakeholders receive value over time rather than everyone all at once.

Grant Resource Entitlements via Roles

Principle: Persons are granted access to resources via membership in a group or assignment to an appropriate role.

Rationale: Managing access rights through groups and roles is a widely accepted best practice in the security industry.  The primary advantages of this approach are:

  • Supports role and group hierarchies
  • Allows for fewer entitlement rules. One rule applied to a group or role allows or denies access to many persons
  • Reduces the need to change entitlement rules.

This makes it easier to manage access to resources in organizations with large numbers of resources and/or users and provides much greater transparency.

Implications: Entitlements to resources will not be directly granted (or actively denied) to persons.

Requires business processes to define and manage roles.

Use currently supported technologies from IAM Technology Roadmap

Principle: Use technologies identified as currently supported on the IAM Technology Roadmap, and contain or actively retire those that are identified as deprecated.

Rationale: In order to maintain a sustainable infrastructure footprint, older technologies must be retired to create capacity to support newer technologies. The IAM Technology Roadmap defines currently supported technologies and identifies future technologies for exploration, as well as defining a plan for retiring services that are becoming obsolete.

Implications: New services should use current or emerging technologies on the IAM roadmap. Services identified as legacy will continue to be supported for a period of time for existing customers. Exceptions are allowed where a critical need cannot yet be met by the new system or where an upgrade of the legacy is necessary to maintain vendor support or to address a significant risk. UW-Madison's Division of Information Technology (DoIT) Middleware System Technology (MST) management are consulted and approve any changes to legacy systems or the addition of new campus and/or UW-System customers.

Evaluate customizations against business value and risk

Principle: Customizations should be evaluated against business value and risk to ensure that all costs and impacts are understood.

Rationale: Deep customization can greatly increase cost and risk over time. Evaluating customizations against business value and risk will guide customers and the IAM infrastructure in identifying long-term implications to security, support, sustainability and other key factors when considering customizations.

Implications: Any potential customization will be analyzed and only those that provide significant benefit to the University will be considered.  The impact of the customization on our ability to maintain the system will be considered.  The potential for the customization to impact the security of the system will be considered.  The implementation and maintenance plan for the customization will address ways to mitigate impacts and risks.

Knowledge Transfer

Principle: Transfer knowledge when working with consultants. 

Rationale: The option of hiring consultants may or may not be viable as time goes by. UW-Madison Division of Information Technology (DoIT) staff must be prepared to maintain and evolve any solution. 

Implications: When engaging consultants, project teams develop plans for working with the consultants and ensure that appropriate knowledge is documented and transferred to DoIT staff. Formal handoff from consultants to DoIT staff should include system documentation, code reviews, maintenance and monitoring plans and other key information.

Ongoing Support

Principle: Consider ongoing support when designing a service.

Rationale: IAM services are critical to the success of UW-System institutions. Documented operating and administrative procedures executed by a service team lead to better customer service, improved availability and frees DoIT's Middleware staff to focus on implementing new as well as enhancing existing services.

Implications: Services are designed such that appropriate service teams can handle all administration and most routine maintenance. A transition plan including appropriate operating and administration documentation is created for each service.

Life-cycle Approach

Principle:  Manage the complete life-cycle of an identity.

Rationale: IAM solutions often fail to address subject deletion, inactivation and archiving. This leads to problems with exhaustion of the namespace (a collection of names, no two of which are identical) and subjects with authorizations that are no longer justified.

Implications: New services are designed to address the complete life-cycle of subjects with the assumption that all subjects will eventually need to be deleted, inactivated or archived.  Campus and System policies may need to be created or modified to address the complete life-cycle.

Authentication Methods

Principle: Require campus users to use secure, scalable, institutionally supported authentication methods wherever possible.

Rationale: The use of methods and protocols not specifically designed to provide authentication services put at risk the confidentiality, integrity and availability of resources and data.

Implications: Users are required to use institutional authentication and access control methods wherever possible. Exceptions are allowed where a critical need cannot yet be met by the institutionally supported infrastructure or an exception is necessary to maintain vendor support or to address a significant risk. UW-Madison's Division of Information Technology (DoIT) Middleware System Technology (MST) management, in collaboration with the appropriate governing bodies, are consulted and will approve any changes to legacy systems or the addition of new campus and/or UW-System customers.

Externalize authentication, authorization and identity functions from applications wherever possible

Principle:  Externalize functions for authentication, authorization and identity management wherever possible through the use of federation or service oriented architecture (SOA).

Rationale: Federation and SOA technologies provide the most flexibility in upgrading and managing our IAM infrastructure over time. Federation and SOA technologies make it easier to deploy services that integrate with a wide-range of campus applications without one-off customizations. Deploying services via the enterprise infrastructure supports ongoing management and security.

Implications: Application developers should design and procure applications that allow for externalizing authentication, authorization and identity functions through the use of federation and SOA. Direct authentication by the application and direct access to identity data is strongly discouraged (e.g. Lightweight Directory Access Protocol (LDAP), Structured Query Language (SQL), views, etc.).

Standard Protocols

Principle: Use standard protocols to communicate between IAM components and with campus systems.

Rationale: Standard protocols are the most likely protocols to be supported by future versions of campus systems. Standard protocols provide the most flexibility in the face of future changes at the application, IAM system or other technology level.

Implications: All new development should make use of standard protocols (Security Assertion Markup Language (SAML), Service Provisioning Markup Language (SPML), Directory Service Markup Language (DSML), Lightweight Directory Access Protocol (LDAP), etc.) wherever possible. Use of other methods of communication are discouraged.

Auditing

Principle: Accurately record and provide for examination of IAM transactions.

Rationale: A mature IAM system must enable appropriate campus users, UW-System users and external parties (e.g. Internal Audit, UW Madison IT Security, regulatory agencies, etc.) to fully understand how identity data is and has been used as well as who has accessed what secure resources.

Implications: Auditing requirements must be identified, documented and implemented for IAM services.

Integration

Principle: Facilitate integration with well defined service definition and loose-coupling.

Rationale: A focus on integration increases the likelihood that future changes can be accommodated. Well defined services limit the tendency to modify services for a purpose for which they were not intended. Loose-coupling allows for more incremental evolution of the IAM system with reduced impact to campus or UW-System customers.

Implications: Service documentation defining the functionality provided. Interaction with services is through loosely-coupled interfaces reducing the need to modify campus or UW-System systems should the service require changes.

High Availability and Disaster Recovery

Principle: Design IAM services to support high-availability and disaster recovery.

Rationale: IAM services are critical to the success of UW-System institutions. Extended periods of service unavailability or loss of identity data could have severe negative impacts. IAM infrastructure must be at least as highly available as the most critical application served by the infrastructure. 

Implications: Design documents and implementation plans detail how the service was designed in order to meet or exceed its availability and recovery goals. Recovery procedures are documented for each service.

Security

Principle: Ensure the confidentiality, integrity and availability of identity data.

Rationale: A key goal of implementing an institutional IAM infrastructure is to ensure the security of identity data.

Implications: IAM project teams collaborate with UW Madison IT Security, the IAM Technical Advisory Group (IAM TAG) and the UW Technology and Information Security Council (TISC) in the design and review of new services. New services are designed to comply with organization or industry security frameworks as appropriate (e.g. Credential Assessment Framework, ISO 17799, etc.).

Minimize Duplication

Principle: Minimize the duplicate storage of identity data.

Rationale: The confidentiality and integrity of identity data is put at risk when it is duplicated.

Implications: Deploy highly available, easy to implement, full-featured services that allow appropriate users to obtain identity data from the institutional Identity Management when they need it. Where duplication cannot be avoided, as little Identity Management data as possible is replicated to campus or UW-System systems.

Provide a single source of identity data (MDM)

Principle: Provide and manage a single authoritative source of identity data through Master Data Management (MDM) technologies

Rationale: Identity reconciliation between sources creates a tremendous amount of complexity and support burden for our IAM infrastructure. Providing a single source of identity information simplifies the infrastructure and reduces data complexity while raising data quality. 

Implications: Providers of identity information should migrate towards integration using MDM technologies. In the short term, no new sources of identity information should be created. In the long term, current providers should explore externalizing their identity stores to a central identity repository.

Governance

Principle: IAM infrastructure and data should be managed by a strong governance process

Rationale: IAM infrastructure and data crosses many technical, organizational and political boundaries. As such, a strong governance model is needed to ensure that the infrastructure and data is deployed and used with appropriate policy, process and organizational controls.

Implications: IAM infrastructure technology development and application integration with the IAM infrastructure (including data integration) should be subject to oversight by the appropriate governance groups.

Future Technologies

Principle: Invest in the exploration and investigation of future technologies

Rationale: The development cycle for deploying a new IAM infrastructure service can be lengthy and it is critical to invest in the exploration of new technologies so that the IAM infrastructure can evolve to keep pace with the needs of applications.

Implications: IAM infrastructure development and support models must accommodate exploration of future IAM technologies.

  • No labels

1 Comment

  1. (From Paul Donahue)

     

    Here is a piece of feedback on the section named “Provide a single source of identity data (MDM)”
    While MDM may be desirable for DoIT I think schools, departments, and research business units will have needs that are outside our person hub and that we should not be so rigid in saying “In the short term, no new sources of identity information should be created.”
    Perhaps that sentence should be deleted and what will remain is good enough for now.
    When DoIT is able to provide a full blown spec pop that includes ways to get identity data in there, edit, and delete it, and allow for localized attributes, and allow linking from trusted sources and no linking from untrusted sources, then we can be forceful. (Unless we direct them today to SpecAuth)
    A new guiding principal might gets its legs from this discussion. That is, to strive for federation over making new campus credentials. And to replace local user and password systems with the campus authentication system as was done for WEMPEC using the Manifest email invitation to establish NetIDs for off campus affiliates in industry.