Evolution of IdM Architecture

advertisement
Evolution of IdM Architecture
1990s to 2020s
Bob Cowles – bob.cowles@gmail.com
BrightLite Information Security
TNC2014 -- 20 May 2014
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
AuthN
1
User
2
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
VO
Ident
3
2
User
AuthN
1
Token Provider
(offline)
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
1
SP
SP
SP
Portal
VO
Job
Ident
Token Provider
(online)
User
Factory
AuthN
2
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
•…
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
Download