1 / 12

Single sign-on authentication: introduction

Single sign-on authentication: introduction. GWS-WG session, IVOA interop meeting, Kyoto, May 2005 Guy Rixon. SSO: what does it mean?. Allow the user to exercise all pre-agreed rights in the VO by signing on once, per UI, per interactive session, to any conforming UI.

wood
Download Presentation

Single sign-on authentication: introduction

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. Single sign-on authentication: introduction GWS-WG session, IVOA interop meeting, Kyoto, May 2005 Guy Rixon

  2. SSO: what does it mean? • Allow the user to exercise all pre-agreed rights in the VO by signing on once, per UI, per interactive session, to any conforming UI. • As above, but signing on once per session to any conforming UI is sufficient to make all rights available via all conforming UIs.

  3. Basic requirements • Let resource providers make authorization decisions. • Follow “natural” patterns of access based on agreements between communities and groups. • Supply credentials to inform auth. decisions. • Unlock all user credentials with one sign-on per session. • Make it as simple as possible (but no simpler!)

  4. Axiom: users are registered • User has to establish an identity once (single registration) to use the VO. • Have to authenticate this identity to resources to get in. • Registration generates credentials for authenticating to services.

  5. Issue: where are users registered? • Separately by each service provider (e.g. each archive site)? • Centrally in the IVO? • Centrally in regional VO project? • In their natural community (e.g. university department)?

  6. Issue: when are credentials issued? • At registration, direct to human user? • At session sign-on, to user’s agent?

  7. Axiom: we support groups • Service provider grants access to groups of users • S/w making auth. decision needs access to group details and membership.

  8. Issue: where are groups defined? • Separately at each service provider? • By user communities? • Same place as users are registered? • Somewhere else?

  9. Axiom: we use digital signatures • For s/w agents authenticating to services: • We use public-key cryptography • We use X.509 identity certificates • Certificates issued by CAs • C.f. human users signing on to VO at start of session • Probably use passwords for that

  10. Issue: how are certificate issued? • Who by? • National/commercial CAs (outside IVO)? • Central CA for IVO? • CAs in regional VO projects? • CAs in user communities? • To whom? • To human users (reusable, long-term cert.) • To s/w agents (single-session proxy cert.)

  11. Axiom: we support delegation • Some work is delegated between a chain of services • e.g. Application -> workflow engine -> DAL -> VOStore. • Delegation of work implies delegation of access rights.

  12. Issue: is delegation controlled? • Use of service implies delegation of all user’s access? • User can veto delegation? • User can specify delegation of specific right • E.g. write once to particular file on particular VOStore.

More Related