A Single Sign-on mechanism for Widgets


Published on

Published in: Travel
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

A Single Sign-on mechanism for Widgets

  1. 1. A Single Sign-on mechanism for Widgets Daniel Dahrendorf (IMC) ROLE Developer Camp, Lausanne, Switzerland August 26, 2010 © www.role-project.eu
  2. 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. 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. 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. 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. 6. Fulfillment of the requirements (Gonzalez et al.) 26.08.2010 © www.role-project.eu
  7. 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. 8. First Suggestion: A Central Identity Provider using OAuth Based on ScalableOAuth 26.08.2010 © www.role-project.eu
  9. 9. Groupwork • Discuss requirements • Develop use cases • Discuss possible technologies 26.08.2010 © www.role-project.eu
  10. 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. 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