identity services goals ① improved and timely access to mit services ② reliable modular...
Post on 19-Dec-2015
217 views
TRANSCRIPT
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.
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
Technical ArchitectureGoal 2 – solved by HW, sysops
• HA topology for key systems: DW, Roles, Moira, etc.
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
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