I want to set up a Keycloak instance which provides AAI to several applications. The users and groups will come from multiple sources (e.g. LDAP) so I want to use mappers so that the attributes on the Keycloak side are the same for users with the same properties. For user attributes, one can use a user-attribute-ldap-mapper, and that works like a charm.
My users now are part of groups, and the groups have their own attributes. So for instance I would have in one of my LDAPs:
Group1
-- MySpecificAttribute1: value
-- MySpecificAttribute2: other value
User1:
-- member of Group1
-- MyUserAttriute1: vall
What I would like to do is to map the attributes MySpecificAttribute1 to Attribute1 in the Group1 group that has been imported into Keycloak.
Is there a (hopefully easy) way to achieve this?
EDIT
I thought it could make sense to specify a bit more what I try to achieve. The thing is we are developing an application that needs to have access to the group information, so answering questions like "give me the list of users who are linked in the contactpoint attribute of all groups". Our current approach is to use the REST API to obtain this data directly from keycloak, and it would not be optimal if we had to implement a translation table for the different sources of information. There may be a way to obtain this information in a different way where we would put the translation somewhere in keycloak, that could be worth investigating too.
Related
Basing on the naming conventions found here : https://restfulapi.net/resource-naming/ , I have a particular question to which I can not find an answer.
Taking the example of customers and accounts where sub-collection resource “accounts” of a particular “customer” can be identified using the URN “/customers/{customerId}/accounts” , how do I find accounts for multiple customer IDs? What are the naming conventions for such a case?
Is the only option to use filters? eg: customers/accounts?customerId=12,22
I tend to avoid filters and keep everything as a urn and keep the implementation of the backend system hidden. e.g. this
customers/accounts?customerId=12,22
means the client needs to know that customers are represented in the system by a variable called customerId. Clients shouldn't need to know that. They just need to know that customers have numbers, IMHO anyway.
This answer shows a solution for your situation, which would look like:
customers/accounts/12,22
although to keep it in line with the domain, where customers have ids and associated accounts, it would look like:
customers/12,22/accounts
and your backend framework would give you the list of customer 'numbers' from the url and at that point they become customerIds.
Not all frameworks may support arrays in paths but pick the right tool for the job and you can design your API to be elegant and a good match for your domain.
I'm looking for an opinion about defining contract for standard GET/PUT/POST/DELETE methods.
We have resource, let's say Client, so route will be /clients
However, we have two types of id for the client. One is the ID generated by our system. On top of that we want optionally allow customers use external id, generated by customer themselves.
So, if customer never going to add clients to the system, don't really interested about integration, and need only use method GET to read customer, endpoint will be:
/clients/{id}
However, if they want full integration, with ability to add clients, and use some their id, we want give them ability to use their own id.
We considered four possible solutions:
1. /clients/external/{externaId}
2. /clients/ext-{externalId}
3. /clients/{externalId}?use-external-id=true
4. /clients/{externalId} with additional header -"use-external-id": true
We are leaning to options 3 and 4 (can be supported simultaneously) but concerns about "restfulness" of such approach. Any opinions on this? What would you choose and why?
REST says nothing about URLs.
How different are internal and external clients? If the only difference is the existence of an externalId property, just use the /clients endpoint and add the property to your client resource. Always assign and use the internal id property in your API, but allow queries to filter by the customer-provided external id also.
How about this:
/clients/client_id/1 - for automatically generated ids
/clients/external_id/d23sa - for filtering on the external_id field
This could be extended to generically filter on any field of a resource and is the approach my company used in developing SlashDB.
We are developing an Access application with a SQL Server backend. We have a table that has records that belong to division A, B or C. The users also belong to role A, B or C. We want each user to see only their corresponding division records, as well as only certain columns.
I've thought of two ways, one making different queries for each role and then, based on the user's role, change the source object of the form. However I don't know if it is possible to retrieve it from SQL SERVER with VBA (all VBA documentation I've found so far is quite lacking).
The other solution I thought was to implement this on the server, however I don't know how a T-SQL query or view could fetch only the information needed based on the user's role
Any ideas?
PS: I can't use functions or stored procedures. For some reason the SQL Server we have been provided has them disabled and IT Ops won't enable them (Don't know the logic behind that).
Okay, it's been a while since I posted this but I'll post the solution I came up with in the end. VBA is not quite necessary in this case. It can be done perfectly with views.
To retrieve the users roles, (inner) join the table database_role_members twice with the database_principals one. Join by Id (from database_principals) on both fields. With this, you get a list of all roles and their corresponding users. To get the roles of the user querying the database simply add a where clause that checks that the user name corresponds with the function USER_NAME.
Then, don't give permission to those roles to access the table we want to restrict access to. Instead, make a view that fetches info from that table and add a where clause that looks up the value from a column against the query that retrieves the user roles.
With this you can make a link in access to the view and will allow you to see only the records that correspond to the user roles.
While this approach is easy, it doesn't allow for more complicated row level security. For a more powerful approach it might be useful to check the following link.
https://msdn.microsoft.com/en-us/library/dn765131.aspx
You could create the same tables with different schemas and assign user rights to different schemas. For example, instead of using dbo.Users you could have Accounting.Users and Warehouse.Users. Assign users in an accounting group to the Accouting schema. Or as suggested above those could be views within a schema that select data from underlying tables.
Would it be viable to use an embedded document roles field for a user table if at most there can be 5 different roles? The reason I ask this is because I believe using an array type for that field would do the same thing. The only time I'd be using the roles field is for checking if the user has the ability to access certain pages/functionality on the website. Am I missing something here? Thanks
I don't really think either approach is incorrect and I think it's more relevant to how you want your models to look than how your data will be stored. It really just depends on what (if any) information aside from the role type that you want to persist and how you plan to check the user's role.
If you're looking to simply store a list of roles (admin, user, moderator, etc) then a serialized array attribute is probably fine. On the other hand, if your roles have more information stored within them (ex. granted actions or privileges for each role) it might be beneficial to build out a UserRole model separately and embed that in your User model.
There is actually another, pretty good option if you're simply storing a list of roles where each user can be a member of one or more roles. You can actually us a bitmask. Using this approach your user roles would be stored as a simple integer and you'd use some of ruby's bitwise operators to map that value to a set of roles.
http://railscasts.com/episodes/189-embedded-association?view=asciicast
I'm trying to make auth with LDAP (Zend_Ldap) and using openldap server.
Groups objects implements two classes: posixGroup and top
Users objects implements two classes: inetOrgPerson, posixAccount and top.
User object has no properties like "memberof", where I can see all user groups.
I can get user to groups relaions from groups propertie "memberuid", but it's not so usable, as in case with "memverof" propety.
Wich classes I must implement for users objects to get memberof field or something similar?
Well the answer is really 'you don't want to do that'. You want to add the user to the group, not the other way around. You can find the groups the user is a member of with a simple search filter.
Having said that, there are dynamic membership and dynamic lists overlays in OpenLDAP that can do this for you. But it's really just putting the same thing as above under the hood.