Shibbolise This!

1,000 views
970 views

Published on

Federated access management without the KoolAid

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,000
On SlideShare
0
From Embeds
0
Number of Embeds
39
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Shibbolise This!

  1. 1. Shibbolise This! Federated access management without the Kool-Aid
  2. 2. Why listen to me? • Involved with directory deployment for a decade • Involved in JISC eFramework and eLearning interoperability projects • I’m a federated-service believer
  3. 3. What we’ll cover • The case against Shibboleth • Considerations for deployment • Alternatives to doing it yourself
  4. 4. The case against Shibboleth • Shibboleth is an ideology not a solution to a problem • Anyway, Athens works - and is far less trouble • The nature of the problem Shibboleth solves is going away
  5. 5. Shibboleth as religion [Web applications] should stop doing authentication. That's the web server's job [...] Web servers are very capable beasts. Applications don't need to do these things [...] Supporting [authentication] directly inside an application is wrong, just as supporting passwords natively is wrong today. Scott Cantor, Ohio State University. Designer of Shibboleth
  6. 6. Athens works • If the access management federation is about access to library resources, isn’t Athens good enough? • Is the poor state of inter-institutional collaboration the consequence of a lack of federated access management?
  7. 7. Time moves on • Shibboleth is a product of an enterprise-centric age • How relevant is this? • The web is becoming more user- centric • VLEs are becoming PLEs • How long before OpenID?
  8. 8. Deployment considerations • Support • Resilience • Security • Directory and SRS • Institutional politics • Available resources
  9. 9. More support • Not just one password - all your users • Will your LRC staff help out ...? • Not just authentication, but authorisation • How will the Federation user interface work? • When do people do web-based access?
  10. 10. Single point of failure - multiple dependencies • What happens when your iDP goes down? • Or your directory service? • Even for maintenance? • Or your DNS, MAN connection, &c... • When did people want to access those web-based services again?
  11. 11. Security considerations • You must provide and manage SSL server certificates • They expire annually • You can’t hot-replace them • On a critical service • The iDP is another server in your DMZ
  12. 12. Directory enquiries • What is your policy for populating your user directory? • What information do you keep? • Attributes for authorisation? • Grouping information matching courses of study? • What is your expiry policy?
  13. 13. Political animals • Who owns student and staff information? • The same people who need it for the Federation? • Will they gather the information you need • And provide it on your schedule?
  14. 14. Photo: 5Lab (Hugh Lunnon) Available resources
  15. 15. Alternatives • Pay to use an outsourced service • Pay to continue using Athens
  16. 16. Outsourcing • Betting on an unknown service • How many problems will outsourcing solve? • How much will it cost? • How much of your time will it take?
  17. 17. Athens eternal? • Don’t bet on it! • You will have to face Shibboleth sooner or later • That likely means getting started now
  18. 18. Thanks! Miles Metcalfe, Ravensbourne College

×