Unified Social Sign-on


Published on

Thoughts on a Unified Social Sign-on 'identity platform' for education, health and government

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Unified Social Sign-on

  1. 1. Unified Social Sign-on<br />An ‘identity’ platform for government websites<br />Andy Powell<br />
  2. 2. Background<br />Eduserv has ~15 year track record as provider of Access and Identity Management (AIM) solutions<br />customer base that includes UK HE/FE, the NHS, Australian Healthcare providers, US, …<br />primary product now known as OpenAthens<br />SAML-compliant - UK Access Management Federation<br />50% UK university market and significant proportion of academic publishers<br />
  3. 3. Emerging trends<br />principle use-case to date – single sign-on to ‘external’ academic content<br />however… seeing trend towards<br />universities becoming providers of services to other universities<br />desire to use single sign-on mechanism for internal resources<br />growing use of social media by staff and students<br />universities and publishers wanting to minimise costs of integration, management, etc. for their ‘access management’ solution<br />
  4. 4. Unified Social Sign-on (USS)<br />USS is our emerging response to these trends<br />possible fit with needs in ‘government’ space<br />an identity and access management solution supporting<br />personalisation<br />controlled access to both content and transactional services<br />based on varying levels of assurance about end-user<br />with possibility of federated solution across government<br />
  5. 5. Possible use-cases<br />user wants to store accessibility preferences across multiple sessions, browsers or government websites<br />user wants to comment anonymously on consultation document<br />user wants to comment on consultation document using their preferred social network identity<br />user wants to share comments via their social network<br />
  6. 6. Possible use-cases<br />user wants to undertake transaction that requires validated email address<br />user wants to undertake transaction that requires confirmation of postal address<br />user wants to undertake transaction that requires confirmation of paper credentials (passport, driving licence, birth certificate, etc.)<br />(last two not included in current USS plans)<br />
  7. 7. Assurance and privacy<br />sliding scale of ‘levels of assurance’ by government provider about who the user is (level 0 thru to level 6)<br />corresponding ‘privacy’ concerns by end-user about how much the provider knows about them<br />possible use of two-factor authentication to increase confidence both for and in the end-user (e.g. username and password and PIN sent to mobile phone)<br />
  8. 8. Functional specification<br />enable sign-in to government website using existing web identity providers and social networks (Google Apps, Facebook, etc.) and/or using local website username<br />email validation<br />optional second factor authentication using mobile phone<br />consistent user-experience across multiple government websites<br />
  9. 9. Functional specification<br />cloud-based solution to minimise effort around installation and management<br />simple API for local integration<br />support for standards – OpenID, OAuth, SAML<br />
  10. 10. Functional specification<br />management console to manage identity providers, local user accounts, services protected<br />integration with social network APIs to allow posting of content on behalf of the end-user (with permission)<br />