Produits Entr'ouvert » Authentic 2

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.

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).

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.

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.

It should also be integrated in the CAS IdP.

• 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)

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 name¹ 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.

Needed in Belgium to allow different authentication levels (eID)

Nope, it's not related.