...
While UCTrust is the first intercampus use of middleware in the University of California, this project is UC's first use of middleware as an application development paradigm. The infrastructure described is specific to the exchange of identity information for user provisioning. It does, however, embody many aspects of a more general-purpose infrastructure for data interchange among arbitrary systems that should be useful in the future.
UP HLD (copied above) can be leveraged after confirmed and updated to reflect additional discovery and detail.
This section is to provide a general description of the software system including its functionality and matters related to the overall system and its design (perhaps including a discussion of the basic design approach).
Principles and Assumptions
- Campus identity and access management systems and the organizations that operate them are authoritative for information about the members of their respective communities. The same campus organization that currently operates Shibboleth IdP (Identity Provider) will be the organization that operates the infrastructure described in this document.
- (Note that much of the IAM's information will likely be aggregated from other systems of record on the campus.; Nevertheless, UCTrust designates the IAM as the authoritative contact for its campus.)
- This framework provides a common mechanism for application systems to obtain identity information from campus IAM systems. Merging the results from multiple IAM systems, however, is left to the application.
- The existing UCTrust agreements, policies, processes, and technology should be leveraged as much as possible. All participating campuses have implemented UCTrust and are operating a recent version of Shibboleth IdP that supports SAML2 (v2.1 or higher).
- Campus IdMS system is capable of capturing changes to identity records. IdMS provides hooks so that provisioning adaptor can retrieve the data.
- The design and implementation must make effective use of University resources. Where possible implementations should be shared and/or reused. Deployment plans should accommodate differing priorities and schedules at different campuses, allowing for inter-campus collaboration and partial implementations at each campus until the entire infrastructure is deployed.
- This effective use of University resources extends beyond this project, in particular by being the first UC-wide deployment of common middleware that can be used by other projects in the future
HLD Principles and assumptions (copied above) can be leveraged after confirmed and updated to reflect additional discovery and detail.
Describe any principles and assumptions regarding the software and its use. These may concern such issues as:
- Related software or hardware
- Operating systems
- End-user characteristics
- Possible and/or probable changes in functionality
General Constraints
Describe any global limitations or constraints that have a significant impact on the design of the system's software (and describe the associated impact). Such constraints may be imposed by any of the following (the list is not exhaustive):
...
- The user provisioning functions supported in this design scope:
- Snapshot
- Subscription
- ChangeLog
- Hardware or software environment
- End-user environment
- Availability or volatility of resources
- Standards compliance
- Interoperability requirements
- Interface/protocol requirements
- Data repository and distribution requirements
- Security requirements (or other such regulations)
- Memory and other capacity limitations
- Performance requirements
- Network communications
- Verification and validation requirements (testing)
Out of Scope
Identity Matching is out of scope for this project and is left to Service Providers to resolve. Please add why.
Anything else out of scope? If so, why?
...