Ticket #118 (closed enhancement: fixed)

Opened 7 years ago

Last modified 6 years ago

Implement Authorization and Authentication

Reported by: business@… Owned by: robert@…
Priority: blocker Milestone: 0.6
Component: General Version:
Keywords: Cc:
Hardware: Operating system: other
Product: URL:


Create authentication based on (nested) groups and users, and think about implementing per class / method ( = on functionality) authentication using interceptors (?) and an extended base controller?

Change History

comment:3 Changed 7 years ago by kees.vanbochove@…

End goal: allowing people to log in and create accounts

  • add Group / User domain classes
  • think of authorization model (make own user/ip/session table or use jsecuser (but that's bloaty?))
  • add Views for creating user account, login (session mechanism)

comment:2 Changed 6 years ago by kees.vanbochove@…

Current main issues:
In wizard, add owner (current user as default) and readers and editors collections.
In modify wizard, check if user is allowed to edit the study.
When viewing study data, check if user is logged in and has access.

comment:1 Changed 6 years ago by j.a.m.wesbeek@…

Today we discussed in the meeting how to go about implementing:

  1. Authentication
  2. Authorization
  3. API (module integration)

It was decided that Tjeerd, Jahn and probably Michael would be asked to implement the technology agreed upon in today's meeting. Hence, I will reassign this issue to Kees for now...

comment:2 Changed 6 years ago by business@…

  • Component set to GSCF in general

The requirements are clear now, they just have to be implemented. On study level, there are three different roles: owner, readers and writers. These are already stored in the domain model now. The consequences of these roles have just to be implemented over the whole GSCF application.

Create login functionality which redirects to an OAuth provider:

  • Define datatable which is a local cache of OAuth users that ever logged in
  • Change Study.groovy owner, readers and writers to point to that table
  • Reroute login requests to OAuth provider and store the logged in user (with OAuth token) in the session
  • Make this logged in user easily available everywhere in the application (see below for where it is needed)

Implement security:

  • Make sure only logged in users can make changes to the system (create studies, edit studies, edit templates)
  • Change 'my studies' to only display the studies the user is owner of.
  • Change 'study list' to only display the studies the user has access to.
  • When a study is created, assign the logged in user as owner
  • Add step to specify additional readers/writers for a study in the study create/modify wizard
  • Add 'manage roles' link to study table in study list where you can specify owner, readers, writers
  • Same, with a link in the study overview of a study (maybe this should be an extra tab, and that 'manage roles' link just goes to this tab?)

Just for reference, the following features have been thought of but will not be implemented in the scope of this ticket.
Nice to have: groups, makes it more easy to add multiple users at once to a study.
Also nice to have: anonymous user, studies that are public / viewable by users that are not logged in

comment:3 Changed 6 years ago by business@…

  • Reporter changed from j.a.m.wesbeek@… to business@…
  • Summary changed from Design and create Authorization and Authentication implementation to Implement Authorization and Authentication

comment:4 Changed 6 years ago by business@…

  • Priority changed from major to blocker

comment:5 Changed 6 years ago by business@…

  • Milestone set to 0.6

comment:6 Changed 6 years ago by business@…

  • Owner changed from kees.vanbochove@… to robert@…
  • Status changed from accepted to assigned

comment:7 Changed 6 years ago by business@…

Actually, the feature 'anonymous user' is very nice to have. If there is a concept like that in Spring Security, it would be very helpful - then a study could be published to the outside world by adding the anonymous user to the readers group of the study. If that is not possible, another way to implement this would be to add a 'public' boolean to the Study class, which should be used e.g. in the study list to determine whether a study is visible to a not logged in user.

comment:8 Changed 6 years ago by business@…

Also, a 'published' field has been added to Study. This field determines whether a study is private (only accessable by the owner and writers) or published (also visible to readers). Please implement that functionality as well.

comment:9 Changed 6 years ago by robert@…

  • Status changed from assigned to closed
  • Resolution set to fixed

THis is added to the trunk. The authentication is done without oauth for now, but uses a local gscf user database. Modules are able to use this database and login procedure as described on the wiki.

Note: See TracTickets for help on using tickets.