1. Shared Services – Technical and Security Considerations
DRAFT
Shared Services – Technical and Security Considerations
CSG - IUPUI
May 14, 2009

2. Technical Evaluation of Shared Services – Web Based
Authentication
Directories/Account Provisioning/Identity Data
Group Management and Authorization
Architectural Considerations and Future Influence
Multi vs. Single Tenant Services Instances
Exit Strategy and Interoperability
Risks of Skill and Capacity Atrophy
Some non-Technical Thoughts
N-Tier problem, out of scope of consideration

3. Directories/Account Provisioning/Identity Data
Transition of service provider account to institutional account or any other combination
Is account linking good or bad?
How to influence shared service providers that are not interested in institutional identity
Attribute release vs. group data
Real-time back to institution for Web Service/LDAP calls vs. identity data replication
Range of position from CIO-ish folks about actual sensitivity of identity data

4. Authentication
Don’t want to replicate institutional credentials to service provider
Technologies like Shibboleth, recommended
Neutralize plethora of authentication methods to single before going to shared service provider
Not all shared services will be able to understand institutional identities e.g. GoogleApps vs. GoogleIMAP

5. Group Management and Authorization
Privacy over group membership
Mapping of institutional groups to access controls in shared service
There is an opportunity to provide a shared group service. e.g. Grouper
There may be an opportunity to provide a shared authority service.

6. Architectural Considerations and Future Influence
Like Kuali Student, there a need for service contract (functional definitions) and the APIs to implement them
From good architectural designs, flow good service levels, scalability, interoperability , security, exit strategies…flexibility, flexibility, flexibility.
How does higher-ed influence these technical designs? Consortia?

7. Multi vs. Single Tenant Services Instances
Exchange example highlighted the functional (and cost) differential between two models
Potential security concerns over partitioning in a multi-tenant instance
Calendar is example of interop limitations demonstrating benefits of a multi-tenant model…or using the same service provider
For lack of a better way to say it…
Evil is good, as long as it scales.

8. Risks of Skill and Capacity Atrophy (consumers)
Once service is sourced elsewhere, over time there is a loss of technical expertise to provide that service
Infrastructure and integration skills tend to persist, as long as we remain in the infrastructure business
Factor skill set persistence in with exit strategy of any shared service

9. Some non-Technical Thoughts
Different viewpoints about whether there is a fundamental difference between shared services providers that are commercial or .edu based, at least on a technical or security level