© www.role-project.eu

A Single Sign-on mechanism for

Widgets

Daniel Dahrendorf (IMC)

ROLE Developer Camp,

Lausanne, Switzerland

August 26, 2010

© www.role-project.eu

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?

Requirements

26.08.2010

© www.role-project.eu

Architecture of Gonzalez et al.

26.08.2010

• LMS provides core

functionality

• Tool is a standalone

application

• User accesses the

LMS to carry out tasks

with aid of the tools

© 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

26.08.2010

Based on ScalableOAuth

© 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