4. Identity Services Goals ① Improved and timely access to MIT services ② Reliable modular utilities (i.e. power, water, phone) ③ Easy integration for vended applications and developers ④ Easy to use; transparent to users; reduced support calls ⑤ Better process for Proofing and On/Off-boarding ⑥ Enables internal and external collaboration ⑦ Improved reputation for institutional identity (mit.edu) ⑧ Better security via timely management of Identity ⑨ Respect the privacy of the individual and community ⑩ MIT becomes a leader in Identity Services, globally

5. Business Benefits Common identity services will increase developer efficiency (no duplication of effort) Consistency of central services can increase security, enforcement of policy Federated identity services can – Enhance opportunities for collaboration – Provide login options besides x.509 certificates

6. Technology Drivers Existing technology is 10-20 years old, MIT- specific, hard to integrate Service-oriented Architecture Shibboleth, InCommon for hi-ed federation LDAP has become a default protocol for integration Acegi (Spring Security) a SASH standard

7. Current State: Identity & AuthN Assets: – Unique ID for all people (MITID) – Kerberos Accounts for all – Wide use of x.509 certificates – Centralized “Athena” provisioning – App certs used for n-tier web services – Shibboleth Web SSO in pilot (Touchstone) Gaps: – Lack single solution for external users – Not yet federated with outside institutions – X.509 Cert is not enough for full Web SSO experience – Shibboleth solution not yet widely used – Some departments do their own thing (e.g. Sloan) – Not everything falls under “Athena” provisioning, many manual processes – Ideal N-tier solution would not need proxies for web services

8. End State: Identity & AuthN – Unique ID for all people and THINGS (?what would this mean?) – Shibboleth-based identity federation, including Kerberos ID, external Identity Providers, and “Identity Provider of last resort” (CAMS) – All IS&T apps use these services appropriately (e.g. Web SSO, extra validation as needed) – Easy integration with 3 rd party applications – Centralized, near-realtime provisioning for all services – Solve the N-tier problem for web services and become famous

9. Current State: Permissions & AuthZ Assets: – RolesDB – Moira lists for group-based permissions, ACLs (plus mailing lists and floor wax) – LDAP instances: ldap.mit.edu, Win Domain AD Gaps: – RolesDB not used for many apps – Apps mostly use data feeds and application-based logic, not real-time service – No easy “plug-in” to 3 rd party applications – No 24/7 High Availability (not trusted as a real-time service)

10. End State: Permissions & AuthZ Turn RolesDB into perMIT, get all IS&T apps to use appropriately Either enhance Moira to use standard protocols or replace with new tool(s) Enhance LDAP (near real-time, Read/Write, more data) Easy plug-in to 3 rd party applications 24/7 High Availability for all infrastructure

11. Current State: People Attributes Assets: – Data Warehouse centralizes all Systems of Record, reconciles all person attributes, feeds LDAP Gaps: – Data obtained thru feeds, not near-realtime – No 24/7 High Availability

12. End State: People Attributes Data Warehouse continues in central role Apps are obtaining person info thru near- realtime standard protocols (e.g. LDAP, SAML) Permissions can be based on a larger range of attribute profiles (e.g. not just group memberships) 24/7 High Availability

13. End State Characteristics Characteristics of Identity Software (CIS) – standard protocols and data formats – Real time updates and access (eliminate feeds) – 24x7, scalable, reliable, modular – integrates easily with vended and OSS products – SDKs for developers – used by others, especially in higher education – Audit-ability

14. Approach to Delivery Identify existing MIT assets that can be grown into more global solutions and do it (e.g. RolesDB-> perMIT) Identify MIT assets for which there are other more widely accepted solutions and migrate all dependent systems – work “outside-in” whenever possible Leverage Kerberos whenever possible Work with OIS to develop HA infrastructure Socialize developers thru SAIS, MAP, Student Vision Work w/CSS, DLCs on provisioning business processes Take it in small steps – demonstrate value to the community as we go

15. Conceptual Architecture (1) Identity Services is the layer of “CORE MIDDLEWARE” supporting the academic, research and administrative enterprises of MIT.

16. Conceptual Architecture (2) Image courtesy of National Science Foundation Middleware Initiative

17. Application Architecture Goal 1, 3, 6 – solved by SW Application Touchstone Kerberos IdP CAMS IdP OpenID IdP InCommon IdP LDAP PerMIT Roles DB DW AuthN Via Apache, Acegi SDK, PHP lib? AuthZ Via SOAP? LDAP? Acegi SDK? MITID Groups Identity & Group Services via SOAP, LDAP?, Acegi SDK? Shibboleth Federation DW

18. Application Architecture Goal 1, 3, 6 – solved by SW 3 rd party app MIT app Web-accessible Services PerMIT People Touchstone Groups MIT admin App Standard Interfaces Apache LDAP MIT interfaces Maybe a diagram like this is better? Not entirely accurate, but perhaps more useful

19. Process Architecture Goal 5, 8 – solved by Business TBD

20. Technical Architecture Goal 2 – solved by HW, sysops HA topology for key systems: DW, Roles, Moira, etc.

21. User Experience Goal 4 – how to solve? TBD – current Touchstone process is not seamless

22. Aspirational Goals? Goals 7, 9, 10 ?How would these affect our architecture, deliverables, plans? ?How would they be measured? ?What is the difference between a goal and a guiding principle?

23. Who will lead IdS strategy development? – Gettes Who else is involved? – Repa, Hill, Thorne, Schiller, Tom Barton, RL Bob Morgan, Alexandra Ellwood, George Petrowsky + Ron Parker

24. Appendix Slides from previous versions

25. Risks of providing Identity Services Centralization concerns: – Single point of failure (the lights go out or the water stops running or the phones don’t work) – DLCs might perceive IS&T as obstacle or overseer If not seen as good enough, the community will do its own thing Reduced value of evolving technology and the importance of identity in the world Perceived fear: Standardization sometimes stifles innovation.

26. Risks of NOT providing Identity Services The Balkanization of identity in the community Administrative inefficiencies will increase Significant overhead and complexity for users Duplication of IT development Institutional identity lost (goes to ~Google) MIT becomes lead story in the news because of Privacy Spills or increased Identity theft

27. Desired End State All applications coming out of IS&T make appropriate use of Identity Services Majority of MIT community use Identity services Everything appropriate has a unique ID Federated access beyond the web profile (such as N-Tier problem, mobility) Near Real-time provisioning to applications Services built on technology used globally

28. Current State + Approach to Delivery Persons = MITID, Data Warehouse Person Registry Accounts = Kerberos Organizations = Master Dept Hierarchy and “Relations” system (ASQ) Groups = Moira, Stellar, RolesDB Privileges = RolesDB evolving into perMIT Authenticate = Kerberos + Touchstone Authorize = RolesDB, data feeds, little real time Provide Data = RolesDB extracts, DW extracts, Moira Federate = Touchstone Provisioning = homegrown, little to no automated process N-Tier problem = leverage Kerberos + Federating technologies