1 / 6

Evolution of IdM Architecture

Evolution of IdM Architecture. 1990s to 2020s Bob Cowles – bob.cowles@gmail.com BrightLite Information Security TNC2014 -- 20 May 2014. 1990s to early 2000s. S ervices for collaboration provided at a single SP SPs required local identity proofing and authentication

giovanna-abbott
Download Presentation

Evolution of IdM Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evolution of IdM Architecture 1990s to 2020s Bob Cowles – bob.cowles@gmail.com BrightLite Information Security TNC2014 -- 20 May 2014

  2. 1990s to early 2000s • Services for collaboration provided at a single SP • SPs required local identity proofing and authentication • Identity proofing responsibility shared between SP and collaboration • Two-step process – Identity proofing to receive token for later authentication SP Ident VO 1 AuthN User 2

  3. 2000s to early 2010s – Complexity Increases • Non-batch services remained substantially the same • For batch, distributed SPs required distributed IdM • Three-step process – User obtains bearer token from 3rd party provider; registers token with collaboration for membership; then can present SP with bearer token and membership attribute SP SP SP Ident VO 3 AuthN 2 User 1 Token Provider (offline)

  4. Mid-2010s to 2020s – Portals and Federations • AuthN token provider moves online through Federation • Portal simplifies researcher access to services provided by multiple SPs • Return to a two-step process • Portal-as-a-Service is required for collaborations without access to personnel with IT/IdM expertise SP SP SP Portal Ident VO Job Factory AuthN 2 User Token Provider (online) 1

  5. What are the problems to solve? • What attributes do SPs need? -- Direction – Name + membership • Enhanced LoA requirements? (e. g. BioScience) • Privacy issues? • Incident Response • Multiple attribute probviders • Harmonized attributes • Non-web services (e. g. ssh) • Portal complexity (and security) issues • …

  6. Conclusion All problems in computer science can be solved by another level of indirection. Butler Lampson – ACM Turing Award Lecture quoting David Wheeler See also … IETF RFC 1925 https://tools.ietf.org/html/rfc1925 Rule (6)It is easier to move a problem around … than it is to solve it. Corollary (6a) It is always possible to add another level of indirection

More Related