I am aware of adding/managing users from GUI in NiFi i.e. a admin user and add user and groups/policies etc.
This is maintained in users.xml file.
I wanted to know, can we manually add records in users.xml instead of GUI?
If yes, how is identifier tag of user derived by NiFi. For e.g. I see a tag:
How is above identifier generated?
The reason for above is, we can maintain the users.xml file in our code base and whenever new users need to be added in NiFi, team can update its details in this file and release and we re-start NIFi. We do not have to rely on GUI to add new users.
Is it possible?
EDIT:
To be more clear, currently we have ldap authentication in place using ldap-provider. So that part is fine. I am not lookng for ldap authentication to NiFi.
Now for actual roles/permissions for "authorized users" i.e. who can see the processors/components, create new processors, query data provenance etc admin go to NiFi UI and add users/groups/policies etc. These details are then updated in users.xml.
I am specifically looking to achieve this activity via automating or from backend.
As per the response from Bryan, I think the feasible solution is using Nifi REST API for that.
The users.xml and authorizations.xml really shouldn't be manually edited/maintained, they are internals of the file-based authorizer that are not meant to be a public API.
It would be better to maintain a script that looped through a list of users and used NiFi's REST API to see if the user existed, and if it didn't then created the user using the REST API.
Another option would be to load your users from a Directory Server. This is detailed in the admin guide [1]. This implementation is configured with an interval for retrieving new users from the Directory Server.
[1] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#authorizers-setup
users.xml doesn't intended to updated by users. This can be overcomed if you use external authentication providers ex. ldap-authentication provider
Related
First, I'm well aware of the multi-realm approach to multi-tenancy in Keycloak. I've taken over a legacy project where nobody thought of multi-tenancy. Now, two years later, suddenly, the customer needs this feature. Actually, the microservices are prepared for this scenario out-of-the-box.
The customer develops a mobile app that authenticates users via API on our keycloak instance with an account number (as username) and a password. Now, he'd like to add an tenant id to the login information.
The customer wants to avoid using several endpoints as a multi-realm solution would demand.
One first idea was to just concatenate tenant-id and account-id on registration. But that's a smelly approach.
So, my thought was that there may be a way to configure Keycloak in a way that I add a custom tenantid field together with username that acts just like a composite primary key in the database world.
Is such a configuration possible? Is there another way to achieve multi-tenancy behaviour using a single realm?
I can't say for sure, but after some research, I found this:
This website lists all of this together with more information:
https://lists.jboss.org/pipermail/keycloak-user/2017-June/010854.html
Check it out, it may help with your data organization in key-cloak.
Late to the party. But maybe for others who are interested. You could try the keycloak extension keycloak-orgs. I am currently building a test stack with it and I am pleased.
A tenant in keycloak-orgs is an organization. You can map organizations and their roles to token claims with a built-in mapper.
"organizations": {
"5aeb9aeb-97a3-4deb-af9f-516615b59a2d" : {
"name": "foo",
"roles": [ "admin", "viewer" ]
}
}
The extension comes w/ an admin interface. From there you can create organizations and assign users to it. There is also a well-documented REST API on the Phase Two homepage (the company who open-sourced the project).
The maintainers provide a keycloak docker image that has the relevant keycloak extensions installed.
If you want a single realm and singe client that serves many tenants, you can just use custom user attribute and e.g. add key(s) "tenant=MyTenant" and then add a client scope and a mapper to include user attributes that has key=tenant
Then the token will carry the user's tenant(s) and you can use that to filter data, add to newly created data etc.
It's only like 4 steps in Keycloak:
Add User attributes using a key-convention.
Add a Client scope that will represent tenants.
Add a mapper to extract the User attributes.
Add Client scope to the Client in use.
Wrote about it here: https://danielwertheim.se/keycloak-and-multi-tenancy-using-single-realm/
I have the following setup - the Spring SAAS REST service, which allows different companies to manage different events. And there is a rest client (a mobile app) also, shipped separately for each company.
I want to use keycloak for security stuff, and I have a question of how to separate one company from another.
I need companyA to not be able to access companyB event, and also need different roles within the company - some can create events, some can only read it.
First I thought each company will have own realm created in keycloak, but I learned that realm actually specified in the spring boot REST service parameters like
keycloak.realm=demo-realm
Which means it is only one realm per REST application. And I don't want to configure REST service instance per client. I only want one REST rule them all.
Am I trying to use something which really doesn't fit my use case?
Will it be right way to have a keycloack Group configured for each company, and make a logic in such a way that users of one group won't have access to what is created by other group. But then it actually feels wrong, since as I understand group are supposed to be used in a different way - to have admin group and user group, etc, segregating users "vertically" by "privileges", and not "horizontally".
Can you please suggest a right approach for this problem?
I would implement a custom protocol mapper which loads extra user permissions for your application and stores them in a token. This way, you use a single realm and if there are more companies in the future it scales well. Here you've got an example of how to implement it.
Basically, the otherClaims field of the access token is a JSON field that allows a map of properties to be set. You could add a field here such as:
userAccessibleCompanyIds: [1,3,4]
How to load the company ids for the concrete user? You can access your application database from the mapper or get them using the REST API.
Then in your application you need to have a control of what the user accesses. What I do is decode the token and see if the user request suits. If not, return a 403 response.
Is it possible to disable requests sent to Parse without a master key? I'd like to only access Parse through my custom backend and not give users direct access. Does public 'read' set on the User class mean that anyone can read the records in that class? If so, why is this a default - wouldn't that be against good security practices?
Thanks,
Daniel
Public read means that anyone with your api key can read the user collection from your parse server. Api key is not the best approach to protect your app because anybody can know it by putting "sniffing" your network requests.
In order to protect and provide access you can protect your objects with ACL's which allows you to create access for specific user (who is logged in) or to specific role. So you have couple of options:
Create a master user - each user must have username and password and when you create your parse objects make sure that only this specific user create/read/delete and update them. You must only to make sure that when you create an object you create ACL for this user so only this user will be able to modify and read the object. You can read more about parse-server security and ACL's in here: http://docs.parseplatform.org/rest/guide/#security
Using parse cloud code - In cloud code there is a nice feature of useMasterKey which provide full access to any object of parse-server so for each operation that you run (via JS SDK) you can also set the useMasterKey to true and then parse-server will ignore all the ACL's and will execute the query for you. The useMasterKey feature work only in cloud code context so it's safe. If you want to provide additional level of security you can run the cloud code function with your master user (from section 1) and check inside the cloud code for the user session so if the session is empty then you can return an error.
You can read more about cloud code in here: http://docs.parseplatform.org/cloudcode/guide/
This is the code which validate the user session:
if (!request.user || !request.user.get("sessionToken")) {
response.error("only logged in users are allowed to use this service");
return;
}
Above image is the springsecurity.xml file.
Above image is the folder wise I written.
I hope what you are trying to achieve is restricting access based on user role. You can intercept each incoming request and check if the user who is trying to access the url has required role to perform this operation. Please read this link and develop your logic.
We’re currently running the Okta Active Directory agent in order to import our users into Okta.
I'd like to replace this with a custom built process that imports users into a new internal database, for other user-management-related activities, whilst also adding those users to Okta.
Creating the user in Okta is easy, but I also need to get the user's "provider" set to ACTIVE_DIRECTORY, so that Okta delegates authentication to Active Directory.
The documentation (http://developer.okta.com/docs/api/resources/users.html#provider-object) says that the User's Provider field is read-only.
How can I set it?
While you cannot directly manipulate the credential object you can leverage other features available to achieve the desired result.
Create a group in Okta and configure it as a directory provisioning group. From the designated group select 'Manage Directories' add the desired Directory and follow the wizard to completion.
Add the created users to the group (using the API)
You unfortunately cannot set this property as we do not allow the creation of Active Directory users through the public API at this point.
If the purpose of the new process is simply to enrich the user's profile, can't you not achieve this by letting the AD agent sync the users and enrich the profile directly through the API?