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