Project

General

Profile

Development #5262

Manage authorizations to connect to a service provider

Added by Frédéric Péters about 5 years ago. Updated about 2 years ago.

Status:
Rejeté
Priority:
Normal
Category:
-
Target version:
Start date:
12 Aug 2014
Due date:
% Done:

0%

Patch proposed:
No
Planning:
No

Description

At the moment all users are allowed to connect to all service providers; in many cases it would be useful to only present some service providers to some users. (the cdg59 extension to authentic1 did that, and it has again been discussed last week at Certivox).

0001-handling-of-connection-through-a-service-provide-5262.patch View (5.88 KB) Josué Kouka, 20 Oct 2015 12:22 PM

0001-update-french-translation-5262.patch View (49.4 KB) Josué Kouka, 20 Oct 2015 12:22 PM

example.png View (191 KB) Josué Kouka, 21 Oct 2015 05:31 PM

8315

Related issues

Related to Publik - Project management #10245: Gérer les autorisations de se connecter à un service dans authentic Fermé 09 Mar 2016
Related to Authentic 2 - Development #15456: Contrôle d'accès au SSO basé sur les rôles Fermé 16 Mar 2017
Blocked by Authentic 2 - Development #751: Improve the manager based on RBAC Fermé 12 Oct 2011

History

#1 Updated by Benjamin Dauvergne about 5 years ago

I don't think cdg59 is a good inspiration for this feature and there is already another ticket open on the CUD projet for exactly the same thinkg #4775 and there is the very general and old ticket #751.

My current idea woul be to have some kind of permission framework a bit like the one from Django but stored permissions would be by objects and objects concerned would be specified by backends. Permission could be attached to roles (a real role object). Roles could be attached to user or groups. Algebraic data types could be:

Permission = (Action, Object) # ex. (Login, SAML provider#01)

Role = (Name, Slug, [Permission])

UserRoleMapping = (User, Role)
GroupRoleMapping = (Group, Role)

IdP backends would provide basic actions for their service providers 'login/logout', 'defederation', etc.. but also maybe later specific actions created by administrators that would be more like roles on the sp side like 'administer', 'access-back-office'.

I'm gonna link this ticket to #751 where general discussion should continue and Mickaël should get involved since I think he has a lot of ideas on all of this.

#2 Updated by Frédéric Péters about 5 years ago

I don't think cdg59 is a good inspiration for this feature [...]

It represents a use case that should be possible, however the feature is implemented.

My current idea woul be to have some kind of permission framework [...]

I referenced the permission framework in an email, I also think it would be an appropriate direction. (I'll skip details here).

#3 Updated by Benjamin Dauvergne about 5 years ago

Frédéric Péters a écrit :

I don't think cdg59 is a good inspiration for this feature [...]

It represents a use case that should be possible, however the feature is implemented.

CDG59 data model is hierarchical (but with a little bit flat hierarchy) I think an ORBAC approach would cover the CDG59 use case, but
Mike could confirm this better than me.

#4 Updated by Benjamin Dauvergne over 4 years ago

  • Assignee set to Benjamin Dauvergne
  • Priority changed from Normal to Haut

#5 Updated by Benjamin Dauvergne over 4 years ago

  • Target version set to future

#6 Updated by Benjamin Dauvergne over 4 years ago

  • Target version changed from future to 2.1.12

#8 Updated by Benjamin Dauvergne over 4 years ago

  • Target version changed from 2.1.12 to 2.1.13

#9 Updated by Benjamin Dauvergne over 4 years ago

  • Target version changed from 2.1.13 to 2.2.0

#10 Updated by Benjamin Dauvergne about 4 years ago

  • Priority changed from Haut to Normal

#11 Updated by Benjamin Dauvergne almost 4 years ago

New plan for this ticket, in a first time we should add an authorize(user) method to the Service class, it should throw PermissionDenied with a translatable status message if it fails (raise PermissionDenied(_('whatever'))).

A authorized_roles M2M field should be added to service, when not empty the authorize() method should check that the given user is part of those groupes, if not it raises.
A boolean should be shown stating if in case of permission denied, SSO should continue with an error response of if the user should be returned to the homepage with an error message shown.

On SAML 2.0 side the authorize method should be called in the sso code path and handled correctly.

#12 Updated by Benjamin Dauvergne almost 4 years ago

It should also be integrated in the CAS IdP.

#13 Updated by Benjamin Dauvergne almost 4 years ago

  • Assignee changed from Benjamin Dauvergne to Josué Kouka

#14 Updated by Josué Kouka almost 4 years ago

  • Status changed from Nouveau to En cours

#15 Updated by Josué Kouka almost 4 years ago

Patch submission
  • feature
  • test
  • translation

#16 Updated by Benjamin Dauvergne almost 4 years ago

  • service.roles is not related to authorization, it links services to roles visible only to them, it's what i call "service's roles", you really need to add a new m2m field named for example "authorization_roles"
  • this new field must be editable from form on /manager/services/<id>/
  • as a general rule do not use the signals for internal business rule it should be used only for ad-hoc extension, i.e. django is right to use signals, an extension app for Django is right to do it, but an application like Authentic should not
  • authorization should be done by a direct call from SAML and CAS code to the service.check_authorized() method and it should throw PermissionDenied with a translatable message as sole argument (as stated in my previous comment)
  • idp_signals.authorize_service is deprecated as design is wrong and interface is complicated
  • user in role.members.all() does not work as expected as it ignores inherited members, you must do somehthing like (user.roles_and_parents() & service.authorized_roles.all()).exists()
  • I would like CAS support to be implemented as part of this ticket (code is a lot simpler than for SAML 2.0); for CAS message should be shown to user using django.contrib.messages as there is no way to report an error through the CAS response
  • An option on the service object should allow to force showing the message directly on the IdP instead of using a protocol way of returning it to the SP (as for example mod_mellon does not show statusMessage to users)
  • Another option should allow not responding at all to the user but returning to the IdP homepage (some SP does not handle at all any error returned by SAML)

#17 Updated by Josué Kouka almost 4 years ago

8315

Benjamin Dauvergne a écrit :

  • service.roles is not related to authorization, it links services to roles visible only to them, it's what i call "service's roles", you really need to add a new m2m field named for example "authorization_roles"
  • this new field must be editable from form on /manager/services/<id>/

Adding m2m fied in Service related to role won't work since in authentic2.a2_rabc.models.Role there's a ForeignKey related to Service. So, my suggestion is to add a BooleanField to Role Model such as authorized.

Since the relationship between Roles and Service is defined by a Foreign Key, i guess that the only roles which can be authorized are Roles related to the service and not roles from other services. Thus all roles from a services will be listed there and those with the authorized attribute checked should have a their member allowed to connect from this SP

#18 Updated by Benjamin Dauvergne almost 4 years ago

Josué Kouka a écrit :

Benjamin Dauvergne a écrit :

  • service.roles is not related to authorization, it links services to roles visible only to them, it's what i call "service's roles", you really need to add a new m2m field named for example "authorization_roles"
  • this new field must be editable from form on /manager/services/<id>/

Adding m2m fied in Service related to role won't work since in authentic2.a2_rabc.models.Role there's a ForeignKey related to Service. So, my suggestion is to add a BooleanField to Role Model such as authorized.

I don't see any problem here, you can add as much relations as you want between two models, just fix the related name1 if there is a collision.

[1]: https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.ForeignKey.related_name

Since the relationship between Roles and Service is defined by a Foreign Key, i guess that the only roles which can be authorized are Roles related to the service and not roles from other services. Thus all roles from a services will be listed there and those with the authorized attribute checked should have a their member allowed to connect from this SP

No, authorized is not a property of the role but a relation between a role and a service. I don't want to limit authorized roles arbitrarily to those linked to the service, any role can be authorized for a service.

#19 Updated by Benjamin Dauvergne over 3 years ago

#20 Updated by Pierre Cros almost 3 years ago

Needed in Belgium to allow different authentication levels (eID)

#21 Updated by Frédéric Péters almost 3 years ago

Nope, it's not related.

#22 Updated by Benjamin Dauvergne almost 3 years ago

  • Assignee changed from Josué Kouka to Benjamin Dauvergne

Je reprends ce ticket.

#23 Updated by Frédéric Péters over 2 years ago

  • Patch proposed changed from Yes to No

#24 Updated by Frédéric Péters over 2 years ago

#25 Updated by Frédéric Péters about 2 years ago

  • Status changed from En cours to Rejeté

Remplacé par #15456

Also available in: Atom PDF