際際滷

際際滷Share a Scribd company logo

A Single Sign-on mechanism for Widgets

ROLE Project
ROLE Project

This document discusses single sign-on mechanisms for widgets. It outlines requirements including not requiring learners to create accounts for each widget and allowing developers to easily build widgets that require or don't require login. The document describes an existing architecture from Gonzalez et al. that uses a learning management system (LMS) with standalone tools. It also lists 14 requirements from Gonzalez et al. related to interoperability, access transparency, privacy, and more. Potential fulfillment of the requirements and scenarios and suggestions for single sign-on using an identity provider and OAuth are presented.

1 of 11
Download to read offline
A Single Sign-on mechanism for Widgets Daniel Dahrendorf (IMC) ROLE Developer Camp, Lausanne, Switzerland August 26, 2010 息 www.role-project.eu
Requirements Teachers should set up learning spaces where learner are not required to log into the widgets Learners should not be required to create an account for each personalized widget they want to use Developers should easy built widgets which require a log in Developers should easy built widgets which require payment More? 26.08.2010 息 www.role-project.eu
Architecture of Gonzalez et al. LMS provides core functionality Tool is a standalone application User accesses the LMS to carry out tasks with aid of the tools 26.08.2010 息 www.role-project.eu
Requirements from Gonzalez et al. R1: Interoperability. Interoperate between different network domains R2: Access Transparency. Access a tool without being prompted to authenticate if they are already authenticated R3: Privacy. The tool have only access to sensitive data supplied by the system itself R4: Choosability. A user of the system should be able to access whenever he wants the tool R5: Granularity. A user should be able to access particular resources at the tool with different levels of permissions (e.g. readonly, read/write, executiononly) R6: Simplicity. The solution must be simple and scalable R7: Dynamic Reconfiguration. Characteristics of an ongoing authorization to access a tool need to be modifiable 26.08.2010 息 www.role-project.eu
Requirements from Gonzalez et al. R8: Expiry. The system must be able to grant authorizations for a finite period of time R9: Awareness. The system should be able to track the activities of each user at a tool R10: Pseudonimity. Provide some mechanism to set identifiers to its users in order to differentiate their activities. R11: Confidentiality. Sensitive data sent between the user, the system and the tool must be kept confidential R12: Integrity. It must be possible to detect illicit modification on the messages R13: Authenticity. The delegated authorization mechanism must detect whether the user, the system or the tool have been impersonated. R14: Single-use Authorizations. The user cannot reuse any expired authorizations previously granted by the LMS 26.08.2010 息 www.role-project.eu
Fulfillment of the requirements (Gonzalez et al.) 26.08.2010 息 www.role-project.eu
Scenario 2 The learner selects the widget in the ROLE Widget Store and add it to her personal widget store list The learner adds the widget to her PLE via an "add to PLE" button in the store The learner starts her PLE and wants to use the widget The widget requires access to the ROLE Widget Shop and tells the store that it is used from the learners PLE account (2.) The widget requires access to the widget service with the learners PLE account (3.) The widget service asks the ROLE Widget Store if the learners PLE account has the required rights (4.) The ROLE Widget Store checks if the learners PLE account has the required rights for accessing the widget service The ROLE Widget Store responds to the widget service that the learners PLE account has the required rights (5.) The widget service creates a new account for the widget service with the learners ROLE Widget Store account The widget service gives the widget the right to access the service (6.) The learner uses the widget in her PLE 息 www.role-project.eu
First Suggestion: A Central Identity Provider using OAuth Based on ScalableOAuth 26.08.2010 息 www.role-project.eu
Groupwork Discuss requirements Develop use cases Discuss possible technologies 26.08.2010 息 www.role-project.eu
ROLE ALLIANCE PROGRAM What is the Alliance Program? A partner network of strategic users, vendors and other stakeholder Why should I become a member? As a member you have a lot of benefits e.g., access to our showcase platform, free visit of specific workshops, test of prototypes or attendance at Alliance Partner meetings How can I become part of the Alliance Program? Please register under http://www.roleproject.eu/AllianceProgram 26.08.2010 息 www.role-project.eu
References Gonzalez, J., F., Rodriguez, M.,C., Nistal, M.,L., Rifon, L., A. (2008), Reverse OAuth: A solution to achieve delegated authorizations in single sign-on e-learning systems, Computers & Security, Volume 28, Issue 8, Pages 843-856, ISSN 0167-4048, DOI: 10.1016/j.cose.2009.06.002. ScalableOAuth. Online available: URL: http://wiki.oauth.net/ScalableOAuth [19.08.2010] 26.08.2010 息 www.role-project.eu

More Related Content

A Single Sign-on mechanism for Widgets

  • 1. A Single Sign-on mechanism for Widgets Daniel Dahrendorf (IMC) ROLE Developer Camp, Lausanne, Switzerland August 26, 2010 息 www.role-project.eu
  • 2. Requirements Teachers should set up learning spaces where learner are not required to log into the widgets Learners should not be required to create an account for each personalized widget they want to use Developers should easy built widgets which require a log in Developers should easy built widgets which require payment More? 26.08.2010 息 www.role-project.eu
  • 3. Architecture of Gonzalez et al. LMS provides core functionality Tool is a standalone application User accesses the LMS to carry out tasks with aid of the tools 26.08.2010 息 www.role-project.eu
  • 4. Requirements from Gonzalez et al. R1: Interoperability. Interoperate between different network domains R2: Access Transparency. Access a tool without being prompted to authenticate if they are already authenticated R3: Privacy. The tool have only access to sensitive data supplied by the system itself R4: Choosability. A user of the system should be able to access whenever he wants the tool R5: Granularity. A user should be able to access particular resources at the tool with different levels of permissions (e.g. readonly, read/write, executiononly) R6: Simplicity. The solution must be simple and scalable R7: Dynamic Reconfiguration. Characteristics of an ongoing authorization to access a tool need to be modifiable 26.08.2010 息 www.role-project.eu
  • 5. Requirements from Gonzalez et al. R8: Expiry. The system must be able to grant authorizations for a finite period of time R9: Awareness. The system should be able to track the activities of each user at a tool R10: Pseudonimity. Provide some mechanism to set identifiers to its users in order to differentiate their activities. R11: Confidentiality. Sensitive data sent between the user, the system and the tool must be kept confidential R12: Integrity. It must be possible to detect illicit modification on the messages R13: Authenticity. The delegated authorization mechanism must detect whether the user, the system or the tool have been impersonated. R14: Single-use Authorizations. The user cannot reuse any expired authorizations previously granted by the LMS 26.08.2010 息 www.role-project.eu
  • 6. Fulfillment of the requirements (Gonzalez et al.) 26.08.2010 息 www.role-project.eu
  • 7. Scenario 2 The learner selects the widget in the ROLE Widget Store and add it to her personal widget store list The learner adds the widget to her PLE via an "add to PLE" button in the store The learner starts her PLE and wants to use the widget The widget requires access to the ROLE Widget Shop and tells the store that it is used from the learners PLE account (2.) The widget requires access to the widget service with the learners PLE account (3.) The widget service asks the ROLE Widget Store if the learners PLE account has the required rights (4.) The ROLE Widget Store checks if the learners PLE account has the required rights for accessing the widget service The ROLE Widget Store responds to the widget service that the learners PLE account has the required rights (5.) The widget service creates a new account for the widget service with the learners ROLE Widget Store account The widget service gives the widget the right to access the service (6.) The learner uses the widget in her PLE 息 www.role-project.eu
  • 8. First Suggestion: A Central Identity Provider using OAuth Based on ScalableOAuth 26.08.2010 息 www.role-project.eu
  • 9. Groupwork Discuss requirements Develop use cases Discuss possible technologies 26.08.2010 息 www.role-project.eu
  • 10. ROLE ALLIANCE PROGRAM What is the Alliance Program? A partner network of strategic users, vendors and other stakeholder Why should I become a member? As a member you have a lot of benefits e.g., access to our showcase platform, free visit of specific workshops, test of prototypes or attendance at Alliance Partner meetings How can I become part of the Alliance Program? Please register under http://www.roleproject.eu/AllianceProgram 26.08.2010 息 www.role-project.eu
  • 11. References Gonzalez, J., F., Rodriguez, M.,C., Nistal, M.,L., Rifon, L., A. (2008), Reverse OAuth: A solution to achieve delegated authorizations in single sign-on e-learning systems, Computers & Security, Volume 28, Issue 8, Pages 843-856, ISSN 0167-4048, DOI: 10.1016/j.cose.2009.06.002. ScalableOAuth. Online available: URL: http://wiki.oauth.net/ScalableOAuth [19.08.2010] 26.08.2010 息 www.role-project.eu