I'm working on a project where I've multiple ressources and multiple users, what I need to do is to associate different access rignts to every user depending on the ressource he wants to access to
The problem is that a simple LDAP server can't implement this kind of situation,
An idea is to use multiple LDAP servers, one for each ressource, then how could I manage them all?
Or is there another authentication process I can use in this case?
Spring Security has a special ACL module to handle such situations. The basic idea is that each domain object / ressource may have separate access control list. You need to fill this list with appropriate permissions and add corresponding checks in your code. You can have parent -> child relations between the objects to reduce number of permissions. Check it out.
If you have logic behind the access to the resources, you may want to use a rules authorization language such as XACML.
If the assignment of resources to users is arbitrary then the use of ACLs with Spring Security's ACL module is good enough.
The problem is that a simple LDAP server can't implement this kind of situation
Mine does. You use LDAP to define the roles associated with each user, then you use web.xml to associate the resources with the roles that are required to access them, then you configure/write your login module such that it looks up the roles of each user when you login. Container-managed security can do all that.
Related
I'm quite new to the entire auth design and am still trying to understand how to use keycloak for authentication and authorisation.
Currently from what I understand in order to have authorisation enabled for a client you will need to have it in confidential.
After which I am kind of stuck in terms of how to set which policy for which permission.
I have a few types resources but currently placing them all under a single client for simplicity sake.
For my use case I have a workspace for users. So each workspace can have multiple users with different roles of owner,editor,viewer. And within the workspace there are artifacts. So it is some what like designing an authorisation for Google drive.
Would like some advice on how best to design it.
One way I have thought of is using groups and each workspace is a group. Using it to assign users to each group as a way to use the group policy for permission.
The other is really by creating multiple policy and permission for each artifact/resource and adding user to each policy for each workspace.
Would like any advice on authorisation design or even where to begin reading.
After some research I have come to these conclusion.
Yes these can be done by keycloak though most likely shouldn't be done in keycloak itself for its design.
Keycloak itself will most likely be more suitable in terms of authenticating/authorising on services or infra level. So this use case of having user be able to access workspaces or artifacts will be better done in application level having a separated service to handle the permission itself.
That being said if it really needs to be done in keycloak the design that I thought of that is not so scalable is as follow.
Create a policy/user and each workspace/artifact as a single resource. Depending on how many types of access/fine grain control is needed for each type of resource create the scope for each (e.g workspace:view, workspace:edit...). Then create a permission for each resource&scope. This allows fine grain access of basically assigning user to permission of each resource through the user policy.
But of course this design has its flaws of the need of too many policies, permissions and resources so it is better to have keycloak just handle the authentication part and authorisation is just giving users the role to be able to access a service and through the service check if the user is authorised for a certain action.
I would like to know if the following scenario is possible:
A Fiware Orion Context Broker instance, to which different data providers connect to publish their data. For each data item (context), the particular data provider should be able to control which application or data consumer is allowed to subscribe to this context. Is this possible with Orion? How can this be done?
I've looked into the multitenant model, but I guess that is not the proper way to do this. Am I right? Are there any alternatives? You can protect the Orion instance with a PEP proxy, but I guess it does not allow access control on a per subscription basis.
Any hints would be highly appreciated.
The scenario that you propose can be implemented, if I understood correctly, with Steelskin PEP Proxy and the multitenant mechanism (but with some concerns).
In your scenario, your whole application would be a service (indicated in all transactions with the fiware-service), and each data-provider would own a dedicated subservice (indicated with the fiwareservicepath header). All the users (both administrator from the data-providers and final user and applications) would be users of that service. Using XACML, different permissions can be assigned to each possible action and user in different roles. E.g.: you can create a dataProvider role with full permissions under its subservice and a dataConsumer role that should be able just to subscribe and read.
This scenario has some problems, mainly concerning who creates the users and roles and assign roles to users. In order to use Steelskin, you have to map services to Keystone Domains and subservices to Keystone Projects; and users belong to the domain. It's the domain (service) administrator the one in charge of creating the users, so, in your case, data providers would not be able to create new users (and probably, even assigning them as subservice customers).
If you need an example on how to connect these pieces together to achieve this, take a look at:
https://github.com/telefonicaid/fiware-pep-steelskin/blob/master/keystoneInstallation.md
Hope it helps
I'm reading the shiro documentation and never found any signs that shiro supports user groups concept on API level.
I would have expected that Subject.java would have such methods as getUserGroups, but it doesn't. For example, if I write some application which aims to work with numerous authentication systems, when the user creates some object, I would like to make it visible for all users in the object creator's groups, and to do it in an authentication provider agnostic way, using some facade API, like shiro Subject.
But it's looks like I can't doing this using shiro api, is this correct?
How do you support user groups concept in multi-auth applications ?
Should I write some UserGroupAwareSubject extension ?
Shiro as of 1.2 does not have a Group concept in its API - it has the notion of Roles and Permissions.
This is not a problem if you have only Roles or you can use your Group names as what Shiro calls Roles (i.e. realm.hasRole(roleIdentifier, authzInfo) uses your Group name as the 'roleIdentifier').
If you have both Role and Group concepts in your application, you will probably not easily be able to use subject.hasRole for checking both. If you'd like this as a feature, please open a feature request.
Two options for this though if you want to make it work is:
Have one Realm where realm.hasRole calls check against your Roles and another Realm where realm.hasRole calls checks against your Groups.
Use one Realm to perform both and just prefix the strings you use for group checks with a recognizable token, e.g.:
subject.hasRole("group:myGroupName");
Then your realm can check to see if has that prefix, and if so, do a group check, and if not, do a role check.
These options aside, what many people do in this case is ignore Role and Group checks entirely and instead rely on (the more powerful) permission checks in code:
subject.isPermitted("document:1234:read");
Then your Realm can check both the Subject and any of its assigned Groups or Roles to see if they imply that permission. If so, then you don't need any Group or Role checks at all because your code relies on permissions instead of the (potentially volatile and numerous) Groups/Roles concept.
There are some good reasons why permissions are probably better than Role or Group checks, but if you feel otherwise and would still like Groups represented in the Subject API any, please do open a feature request.
Regards,
Les
How do I configure a Shiro to use Active Directory Authentication, but in addition I want to map the usernames to custom roles. I can't seem to find any information on this. Can anyone give me any pointers?
To do Active Directory Authentication use the JndiLdapRealm
For the authorization override the method queryForAuthorizationInfo
Be aware that you probably get group from your AD so you have to provide your own mapping (group to role).
About this shiro reference manual say :
A RolePermissionResolver can be used by a Realm internally when needing to translate a role name into a concrete set of Permission instances.
This is a particularly useful feature for supporting legacy or inflexible data sources that may have no notion of permissions.
For example, many LDAP directories store role names (or group names) but do not support association of role names to concrete permissions because they have no 'permission' concept. A Shiro-based application can use the role names stored in LDAP, but implement a RolePermissionResolver to convert the LDAP name into a set of explicit permissions to perform preferred explicit access control. The permission associations would be stored in
another data store, probably a local database.
Hope this will help
I'm working on doing the same thing, but I'm pretty sure you have to write a custom AuthenticationStrategy. I wanted to authenticate against AD but use the INI to define roles, but I could not get it to behave properly enough to not accept authentication against either (even utilizing FirstSuccessfulStrategy). I didn't get to look into it too much, so maybe one of the Shiro guys who floats around can correct this, but i hit these issues today.
In our application based on Symfony2 we would like to create a list of which of the users in the system that has permissions for a given domain object. We are using ACL and our immediate instinct was to look in the ACL-object returned from the ACLProvider of the domain object in question, for methods that could return the users (or at least SecurityIdentities) that has permissions, but I could not find such methods.
We are certain that this functionality is available through the API, but we cannot find where these methods are hidden.
EDIT An alternative would be to look up these connections in the acl-tables directly and finding out that way, but it would not be very pretty and we would probably be reinventing the wheel.
By default, the Authorization are specified in the file app/config/security.yml. It describe if a Role is allowed or not to access some modules.
There are some differences between Authorization and Permissions.
Permission are not managed by default by Symfony but through specific development (or bundles...)