I have the following requirement: Retrieve the users from OpenAm which are members of a specific group. Alternatively, if possible, retrieve users defined in a specific data store. All this through web-services.
We have our own JDBC data store implementation which reads users from and authenticates users against our database. That works fine. The data store is one of two data stores in our sub realm. The other data store points to an LDAP.
Now I need to read the users (and later the user attributes) from users being defined in the LDAP data store, and only users of a specific group, if possible.
Previously we did that with wso2. There they had a web-service method that allowed you to retrieve users of a specific group only.
Currently I am looking into the IdentityServices web-service of OpenAm, and I am able to list all users of my realm, and get the attributes. But for performance reasons, it would be nice to be able to refine the search. Is that possible? Am I looking at the wrong web-service?
Regards,
Sascha
Related
I only wish to employ Auth0 as my application's API provider but otherwise
would prefer to maintain any and all data about my users within my application's own database, thus, as one might well surmise, my application's database contains a users table along with several related tables. So, once a user signs up for my app, I'd need to create records for that user within the database. Then, once the user logs in via Auth0, I'd like to retrieve that user's data via information contained within the access token. (The field that presents itself as most useful for this purpose is "azp," or "authorized party.")
I'm thinking that, once the user signs up, as part of the effort to create the relevant records within the database, I'd save the "authorized party" value to a field on the users table. (Which field I cannot say, but, for now, this seems as sound a plan as any.) Then, when the user logs in via the Auth0 hosted API, I would retrieve their record from the database via the "authorized party" value.
Does this sound like a reasonable/sound plan? This is my first time building a full-on application from scratch, and, well, this particular detail has me scratching my head.
We are using the CalendarView endpoint to retrieve a users appointments for a specific time period. While calling the endpoint we are passing $select=start,end,showAs to only retrieve the fields that we are interested in.
Our end client is concerned that even though we are filtering the results on our side we still have access to Calendars.Read and technically have access to read meeting subjects, etc. Is there any way in Office365 or the Graph API that our end client can apply more granular permissions to filter which fields we have access to?
Today Microsoft Graph application permissions give your application full access to the entity they cover (all the properties)/the endpoint (all the payload).
There's is no way to restrict access to specific properties of an entity for a specific application.
You can always suggest this idea on uservoice.
This question is regarding authorization, not authentication which i will be managing with passportjs. How do i restrict access for data that's bound to specific users without spreading user_id's all over every table in the database?
Should i create a new database user for each new user of my app and restrict access that way? Or is the "user id in every table" approach actually a good way to go?
I'm working on a project right now where someone else wrote the authorization logic and it works using a kind of authorization path in the code so it can find which user a resource belongs to using some breadcrumb logic.
But I'm really at a loss here and I'm having a hard time finding any information regarding this since almost all articles that I find are about authentication rather than authorization. And I do not mean access to a resource, but rather the filtration of data returned from a resource that the user has access to.
If you want to restrict access of users to certain objects, you either have to store that information with the user or with the object.
The latter is the preferred way because it makes permissions disappear with the object. That's the way PostgreSQL does it – it stores an access control list (ACL) with every object.
So you can either use PostgreSQL to implement privileges (then every application user or at least every group with equal privileges has to have a database user, and you can use permissions on tables and columns and row level security), or you implement it in your application and have some sort of ACL with every row in the database.
I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?
Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...
You could do it either way. First about couchdb users
Users in couchdb are stored in a special _users database
Database permissions are handled by a special _security document. This is specific to every database.
In security documents you add users that you have already stored in the _users database previously.
So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.
Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:
Store your "business logic users" in the special _users database.
Authenticate it with the _session endpoint.
Extract the cookie header and sent it with your application headers.
All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.
If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.
The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.
If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store
It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.
It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.
A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules
The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.
You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.
We are using LDAP based authentication with geoserver which is connected to a PostGIS database.
Users insert rows (features) into the table (layer) using WFS-T after authentication.
Now when users query for data from this layer (also after authentication), we would like to return data that is applicable to this user based on their credential (i.e) only view data that was inserted by that user or group.
We are storing the username in the table. We get the username because this is defined as non-null column in our table and users are required to provide it as a part of their WFS-T insert.
I read about service level security and layer level security, but what we need seems more like row level or feature level security.
We can use JDBC based authentication instead of LDAP if needed, but do not know if this will solve the problem.
I am pretty comfortable with Java and some what knowledgeable on spring security and hence can deal with customizations if needed. Please advice.
You need to use either of role-based access control (rbac) or attribute-based access control (abac). Spring Security will provide you with the former. You'll need XACML for the latter.
Once you know the identity of the user you can determine what role and group they belong to. In XACML you can define a policy which dictates how access is granted. Use XACML if there are relationships between the data you're protecting and the users accessing it.
You'll need a web service filter to intercept the request and/or the response. That filter is called a policy enforcement point in the XACML architecture.
If you have large amounts of data then you want to use something like the Axiomatics data access filter which uses XACML policies to create a SQL WHERE clause used to retrieve entitled data only.
Hth