1 / 17

Evaluation of Shibboleth, PAPI, and A-Select for Our Needs

We evaluate Shibboleth, PAPI, and A-Select to find the best solution for our specific requirements and identify potential solutions that align with our needs.

pellham
Download Presentation

Evaluation of Shibboleth, PAPI, and A-Select for Our Needs

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. UNINETT

  2. An Evaluation ofShibboleth, PAPI and A-Select

  3. What We Are Not Trying To Do • Do a direct comparison between systems • Pick a “best” solution/architecture given our particular needs

  4. Our Motivation • Which features do we really need? • Where are the minefields? • Identify (partial) solutions/ideas that may match our particular needs.

  5. Shibboleth • Well-thought out architecture • Clearly defined system components/interfaces. • Promises to scale well • Indexing server solution.

  6. Shibboleth • Logistics of user ARPs? • Does it scale well? Clubs may help. • FEIDE won't need per-user ARPs. • Integrates existing authN schemes • ... as do PAPI, and A-Select. • No existing authN schemes to consider in FEIDE. • WAYF • Another step on the user's way to the resource. • No percieved need in FEIDE for a WAYF.

  7. Shibboleth • Java (mostly) • FEIDE knows Java. • Supports LDAP as user data source • FEIDE knows LDAP. • Alpha available • Not a trivial task to get up and running. • How about the latest release? • In test phase

  8. Shibboleth: Summary • Attractive architecture • Unneccessary features? • FEIDE doesn't need the WAYF. • FEIDE doesn't need user ARPs.

  9. PAPI • Scalability issues • Potentially a lot of traffic to PoAs. GPoAs will help. • No global index of home organization authN servers – but not necessarily a problem in FEIDE. • User's home org must know which (G)PoAs the user have access to. • Easy integration with existing web resources • Hide them behind a PoA.

  10. PAPI • Privacy issues? • Encrypted user identity code sent between AS and client. • Complete list of accessible resources sent to client after authN; each resource is then contacted.

  11. PAPI • PERL • Too “PERL-ish”? • Supports LDAP as user data source • Again, FEIDE knows LDAP. • Production release available • Currently in use!

  12. PAPI: Summary • It's being used! • Will the basic architecture itself be able to scale well?

  13. A-Select • Not designed for cross-organizational operation • ... although possible with remote A-Select Servers. • No global indexing of A-Select Servers; each Server must know about all relevant remote Servers. • ... but is this really a problem for FEIDE?

  14. A-Select • High degree of inter-component interaction • Lots of arrows in that functional flow diagram... • Especially when involving remote A-Select Servers. • Need to modify applications to use A-Select Agent? • Not an issue with the introduction of filters.

  15. A-Select • Java • Again, good news for FEIDE. • Supports LDAP as user data source • More good news. • Currently in test phase.

  16. A-Select: Summary • Lacks good cross-organizational support • ... but this may not be an issue for FEIDE. • Easy integration with existing authN solutions and web resources • ... especially if filters handle the A-Select Agent interaction.

  17. Questions? cato.olsen@uninett.no

More Related