I have a requirement that I need to restrict the liferay database in site level.
Let me first explain my scenario.
Admin is the one who will create the site and site admins.
Here admin user is the owner and sites are different clients.
Now each site will treat as a different client.
So the site admin have privileges to see only his site related data
in the data base but not others site data.
How can I handle this situation?
Do I need to use the multiple databases for multiple clients/sites?
How do I maintain the different database for different client? Any
suggestion please?
Note: I am not using Organizations, we are using only sites.
I hope I understand what you need. Based on my understanding, you can create separate instance for each client in liferay and use database sharding. Database sharding will allows you to have different db for each client.
HTH.
You can use GroupID to split the users to some groups: Group Admin and Group Normal User.
Not to use different database for diffirent client. Because 2 group have some same points.You need only one database for all of things you want to do.But you can customize it follow GroupID ^^
Good luck!
Related
I have a web-application secured with Keycloak. To keep the description of the service short, we have Users and Documents as entities in the service. The users may have access to none or more documents and may edit or read the document.
Currently we have roles such as Admin, EndUser, Developer etc. We then keep a database table outside of Keycloak that maps the documents to users and what user has what access level to what document. All our end-users have the EndUser role in Keycloak. Every single time an EndUser tries to read/edit a Document, we have to make a lookup in the database table for authorization.
We would like to migrate that table to Keycloak. As I understand it I basically have two options:
Create a lot of roles, two for each document with names such as doc_read_[DOCUMENT-ID] and doc_edit_[DOCUMENT-ID] and so on. Then assign the correct role to the correct user. The downside here is that the number of roles will grow A LOT. Also, the number of roles attached to a user will be very large.
Create a group for each document, with the name of the document id. Have different sub-groups for read/write and then add the users in the correct groups. The downside is that the number of groups will be very large. Also, I will rely Authorization on group names, so the list of group names has to be mapped to the token.
I do not want to add a user-attribute with the document-ids to each user. With this approach I can not get an overview of a document and see what users have access to a given Document.
What is the best practice here? Are there any other solutions to solve this issue? This must be a very common setup.
This is just my opinion.
From what I understand both solutions are suboptimal, adding a role per document is unnatural and too finer grain. And as you already mention this would lead to too many roles that probably you will have to add them into the token.
I would personally use Keycloak just for the authentication part and do the authorization part in the backend. I would also try to group the documents in a way that reflect which user roles are allowed to manipulate them.
Alternatively you might try to use Keycloak's Authorization features to handle that use-case, however I have never used it, so there is not much that I can say about this option.
In my opinion what you want to achieve is something that is very tied to your business logic, I wouldn't recomend depending on keycloak to do it. Your token would constantly grow and management would be a nightmare really.
I see no problem in having a service with good cache to lookup permissions, the bulk of the data won't change much over time.
I'm just want to create a standalone application with CouchDB back-end, but I don't know if I can add a new (ordinary) user without using admin credentials.
In the documentation I just got information about creating an admin user and existing user's permissions:
Only administrators may browse list of all documents (GET
/_users/_all_docs) Only administrators may listen to changes feed
(GET /_users/_changes)
Only administrators may execute design functions like views, shows and
others
There is a special design document _auth that cannot be modified
Every document except the design documents represent registered
CouchDB users and belong to them
Users may only access (GET /_users/org.couchdb.user:Jan) or modify
(PUT /_users/org.couchdb.user:Jan) documents that they own
Here is the relevant part of documentation.
Short answer:
YES, you can
Makes no sense in a registration if you have to use admin credentials to create your account. Anyway, here is an example:
https://serverfault.com/questions/742184/couchdb-user-creation-without-authentication-standard-behavior
In this topic also can be useful this articol:
http://www.staticshin.com/programming/easy-user-accounts-management-with-couchdb
One more tip:
Creating regular users in CouchDB
So I am very interested in using Cloudkit but the documentation on anything over the basic features is horrible. I am looking to establish two basic user types: standard user (someone that can read records only) and an Admin user (can create and modify records). I setup security roles to reflect this and changed the access modifiers on each of the record types to include these roles. However, I cannot find anywhere how to change a user from one role to the other. I have implemented an Admin login of sorts in the app. Once they enter in the appropriate credentials, I want to allow that user to start editing records.
Does anyone know how to do this?
Thanks
I think it's still not possible to assign a security role to a user using code. Then this answer is still valid: How do I access security role in cloudkit
Is it possible to create a site on demand? So in the response of an event, such as button click. I want users to be able to see one site (all users), but users with assigned to a certain group will see two sites.
Also, when would I want to create a seperate web application?
Thanks
Let's try to clear this up.
First, yes it's possible to create sites and webs programmatically, and in that sense you can do it in a click of a button event.
The second part of your question is not related to creating a sub site, it's related to permissions. Sub sites in SharePoint can have different permissions for different users.
So yes, users assigned to a certain group can see sub sites that others can't.
The third question can be answered by this Technet article.
Hope this helps.
Yes, you could use 2 seperate SharePoint web applications to provide access to a single site collection using different authentication providers. Enabling anonymous access for one web app and windows authentication for the other, you could use SharePoint authorisation to setup different permissions on site and pages for anonymous users as noted by Magnus.
Is user profiles an appropriate place to store things like number of items per page in a custom grid user selected? (I you can store it in the view, but it won't be per user this way).
My first though was to store these settings in user profiles, but there are problems with access permissions for programmatically creating user profile properties boiling down to you either have to give every user 'Manager User Profiles' permission in SSP or you have to run the application pool under a domain user, not NETWORK SERVICE. Both scenarios are unrealistic for me, so I'm now looking for another way to store such 'per user' settings.
Thanks!
Edit: I'm now considering ASP.NET profile mechanism with an additional DB to store user properties.
Given that the information is not sensitive a simple database with values stored against AD login should suffice.
And as you have the ASP.Net user database already, storing the information there would be the best option.
Maybe a Global List, that is only accessible for the SHAREPOINT\SYSTEM User and that you can then Query in a SPSecurity.RunWithElevatedPrivileges Function.
Disadvantage: You require Custom code to read/write to that list.
Cookie?
Sure they have limitations, but it is fairly easy to create the control to run javascript to add/edit the value