I recently started working with Wolkenkit and I was wondering if there is a possibility of implementing some sort of role concept yet?
I already found Wolkenkit: ACLs for authorization and user roles which is already quite interesting, and gives me a first idea on how to solve that, but at the same time it is not exactly what I need.
In my Use-Case I need a dynamic role concept which can be changed at any time in order to grant and revoke access to certain parts of my application.
Ideally it would be a mechanism that allows me to associate commands and events with multiple roles at run-time. Are there any new approaches on this topic or any examples where this is already done?
Thanks for the help in advance.
The authorization concept of wolkenkit is based on tokens.
Hence, the simplest thing to do is to have the identity provider add claims for roles, as described in ACLs for authorization and user roles (which is the article you already linked to). This works out of the box, and you do not have to provide and special logic to your wolkenkit applications except to read the token and evaluate its claims. However, this is only suited for static role models, as you'd need to change the identity provider's configuration every time a role assignment changes.
If you require a more dynamic approach, right now unfortunately you are left to your own devices. What you could do is to add a property to your aggregate that contains an array of roles (or user IDs) that you want to be able to access the aggregate. Then, in each command, you would need to check the current user against this array. But still, this means that you have predefined roles, you just could allow or restrict access to aggregate at runtime for specific roles.
If you require an even more dynamic approach, such as making up roles ad-hoc, e.g. to share data with a group that you just want to create at hand, you end up with what we call group-based authorization. Right now, there is no support for this, and AFAIK nobody has yet implemented something like that. Support for this is on the wolkenkit roadmap, but right now unfortunately there is no ETA available (maybe this is something you could contribute to wolkenkit?).
Either way, you need to make sure that your identity provider is configured correctly and wolkenkit is setup accordingly, as described in wolkenkit redirects to Auth0 even when user is logged in.
Disclaimer: I'm one of the core developers of wolkenkit, working at the native web (the company behind wolkenkit), so please take my answer with a grain of salt.
Related
Currently I'm working on system, that uses ZendFramework2 Acl implementation for managing user roles and permissions for various parts of it. Till this moment it works as is supposed to do - giving or rejecting users based on their role. Recently we got a new feature request - implement functionality that allows permission management per user, regardless the role he or she has. Here comes the tricky part - Zend implementation of Acl doesn't met the requirements out of the box (if it supposed to do so at al). Just to note - system is already tightly integrated with the current model, so it will be pain of heart to use another kind permission management model.
So far the best solution I could think of was to represent individual users as roles in Acl and grant them appropriate privileges, so it is possible to dynamically create or delete resources and privileges for users, without impacting overall role permissions (which still apply).
Could I get some suggestions please? Is this the "right way" or there better approach to the problem? Thanks in advance :)
If an user by the fact to be himself has some privilegies, then you have to create a new role for that user.
I have just developed an ACL module that allows you to manage access to each route only creating a new key in each route called 'roles'. You do not have to configure the ACL creating allow rules manually, this module creates the rules automatically for you reading the routes.
You can have a look: https://github.com/itrascastro/TrascastroACL
Is there a framework or common pattern for implementing dynamic permissions?
Something like Rolify but where I wouldn't have to restart the server.
I guess I could just iterate through each User that has a role and add/remove permissions but that seems like overwork.
This reminds me a lot of this question.
Your question is very difficult to understand because all the role-based access control gems like rolify allow the implementation of dynamic permissions.
So, I'm left wondering if, like the other question that I linked to above, perhaps you've misunderstood the way to use these role-based systems.
The idea is that you grant access/permissions to roles (not individual users) and then you assign users to as many different roles as they need in order to have the access/permissions that they need. Obviously, you can assign users to roles dynamically, that's what these libraries provide.
I am building a website for a client that wants to be able to make edits to things on their website. As such I need a way to allow the client to login to the site to make their changes.
My initial thought was to make an authentication system that relies on a User table in the database that is capped at one and only one user. It seems sort of overkill however to make a database table for just one result, so I was wondering if there were any other approaches or best practices that anyone could point to for building a site with just one user.
You could simply authenticate with a static password that is received from a file(encrypted), if you do not want a db model for that.
However, setting authentication with a gem like Devise is like 10 minutes of work. In order to be more secure(it can be a matter even in single user apps), you can set it up and be fine :)
I would highly recommend you set up authentication. As SpyrosP said it does not take long when you use Devise.
I'm slowly but surely putting together my first rails app (first web-app of any kind in fact - I'm not really a programmer) and it's time to set up a user registration/login system. The nature of my app is such that each user will be completely separated from each other user (except for admin roles). When users log in they will have their own unique index page looking at only their data which they and no-one else can ever see or edit. However, I may later want to add a role for a user to be able to view and edit several other user's data (e.g. a group of users may want to allow their secretary to access and edit their data but their secretary would not need any data of their own).
My plan is to use authlogic to create the login system and declarative authorization to control permissions but before I embark on this fairly major and crucial task I thought I would canvas a few opinions as to whether this combo was appropriate for the tasks I envisage or whether there would be a better/simpler/faster/cheaper/awesomer option.
What about cancan by Ryan Bates?
Here you can get a complete visual guided implementation
Take a look at this, it might help:
Basic Rails 3 engine utilizing Authlogic, CanCan and Easy Roles
What about Devise? Take a look at the railscasts.com site.
I was wondering how other people implemented this scenario. I have an internal rails app ( inventory management, label printing, shipping,etc). I'm rewriting security on the system, cause the old way got to cumbersome to maintain ( users table, passwords, roles) - I used restful_authentication and roles. It was implemented about 3 years ago. I already implemented AuthLogic with ruby-ldap-net to authenticate users ( actually that was surprisingly easy, compared to how I struggled with other frameworks/languages before). Next step is roles. I already have groups defined in Active Directory - so I don't want to run a separate roles system in my rails app, I just want to reuse Active Directory groups - since that part of the system is already maintained for other purposes ( shared drives, backups, pc access, etc)
So I was wondering if others had experience implementing permissions/roles in a rails app based on groups in Active Directory or LDAP. Also the roles requirements are pretty complex.
Here is an example:
For instance I have users that belong to the supervisors group in AD and to inventory dept, so I was that user to be able to run "advanced" tasks in invetory - adjust qty, run reports, however other "supervisors" from other departmanets, shouldn't be able to do this, also Top Management - should be able to use those reports (regardless weather they belong to the invetory or not), but not Middle Management, unless they are in inventory group. Admins of the system (Domain Admins) should have unrestricted access to the system , except for HR & Finances part unless they are in HR ( like you don't want all system admins (except for one authorized one) to see personal info of other employees).
I looked at acl9, cancan, aegis. I was wondering if there are any advantaged/cons to using one versus the other for this particular use of system access based on AD. Suggest other systems if you had good experience.
Thank you!!!
ActiveLDAP (Documentation, Github) has some of the features you're looking for, specifically:
You can map LDAP objects (Object Class instances) to objects in a Rails application. The API doesn't mirror ActiveRecord exactly, but it's pretty easy to understand and learn.
It's obviously not possible to join, etc. across LDAP and Relational Databases, but you could write some mildly clever code to make composite data easily accessible from either the ActiveLDAP object or the ActiveRecord object.
ActiveLDAP also provides methods to write to LDAP which allows you to manage your users and roles in LDAP from rails, eliminating the requirement to manage a user table in the database, however, a user database table would likely still be necessary to store application specific data about a user.
Additionally, you could integrate AuthLogic with ActiveLDAP. Here's one attempt I found of just that: LDAP Pass-through Authentication with Authlogic and ActiveLdap
You could then use Declarative Authorization (Pundit) to handle your roles and authorization.