Identity Services Goals ① Improved and timely access to MIT services ② Reliable modular utilities (i.e. power, water, phone) ③ Easy integration for.

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

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

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

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

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 3rd party applications– Centralized, near-realtime provisioning for all services– Solve the N-tier problem for web services and

become famous

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 3rd party applications– No 24/7 High Availability (not trusted as a real-time

service)

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 3rd party applications• 24/7 High Availability for all infrastructure

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

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

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

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

Conceptual Architecture (1)

Identity Services is the layer of “CORE MIDDLEWARE” supporting the academic, research and administrative enterprises of MIT.

Conceptual Architecture (2)

Image courtesy of National Science Foundation Middleware Initiative

Application ArchitectureGoal 1, 3, 6 – solved by SW

ApplicationApplication

TouchstoneTouchstone

Kerberos IdP

Kerberos IdP

CAMS IdP

CAMS IdP

OpenID IdP

OpenID IdP

InCommon IdP

InCommon IdP

LDAPLDAP

PerMITPerMIT

RolesDB

RolesDB

DWDW

AuthN Via Apache, Acegi SDK, PHP lib?

AuthZVia SOAP?LDAP? Acegi SDK?

MITIDMITID

GroupsGroups

Identity & GroupServicesvia SOAP, LDAP?, Acegi SDK?

Shibboleth Federation

DWDW

Application ArchitectureGoal 1, 3, 6 – solved by SW

3rd party app3rd party app MIT appMIT app

Web-accessible ServicesWeb-accessible Services

PerMITPerMIT PeoplePeopleTouchstoneTouchstone GroupsGroups

MIT admin App

MIT admin App

Standard InterfacesStandard Interfaces

ApacheApache LDAPLDAP

MIT interfaces

Maybe a diagram like this is better? Not entirely accurate, but perhaps more useful

Process ArchitectureGoal 5, 8 – solved by Business

• TBD

Technical ArchitectureGoal 2 – solved by HW, sysops

• HA topology for key systems: DW, Roles, Moira, etc.

User ExperienceGoal 4 – how to solve?

• TBD – current Touchstone process is not seamless

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?

• 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

Appendix

• Slides from previous versions

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.

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

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

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