creating a role based authentication system in Postgresql - sql

I am writing a software on java that connects to postgres db via jdbc. How can I create an authentication system so that user can connect to db with a predefined db role and create tables that will have a reference to this user?

You have to mention the username, authentication type, database name and the server IP from where you are connecting in the pg_hba.conf file of postgresql database cluster.
If you want the user to be authenticated from that ip automatically, mention the authentication type as trust, or ypu will have to create a .pgpass file mentioning the username and its credential in it.

Related

keycloak managed password with federated users

Is it possible to manage the password by keycloak with federated users? I have users
federated from external database and currently also the password is being checked from the external database.
Is there a possibility to register a password in keycloak for the user just after that user is created in the external database and then federated to keycloak?
My motivation is having the built in password reset functionality of keycloak not building extra SPI code for this on federated users.
It is not really clear from your question, but since you have federated users from an external database, I assume you have implemented your custom UserStorageProvider. You are also validating passwords against your external database. So, I assume you have also implemented CredentialInputValidator interface. If you have not implemented CredentialInputUpdater, I would assume what you are trying to achieve should work out of the box.
If you have implemented CredentialInputUpdater, you could try to do the following:
Within you implementation of CredentialInputValidator.isvalid first check if the user has a local password configured, e.g. like this
keycloakSession.userCredentialManager().isConfiguredLocally(realm, user, credentialInput.getType())
If this is the case (returns true), simply have isValid return false. In this case Keycloak should use other CredentialInputValidators and check for the locally configured password.
If this is not the case (returns false), do the password check against your external database. Iff the password is valid, silently migrate the password to Keycloak's local credential store. This could look something similar to this:
CredentialProvider passwordProvider = keycloakSession.getProvider(CredentialProvider.class, PasswordCredentialProviderFactory.PROVIDER_ID);
if (passwordProvider instanceof CredentialInputUpdater) {
((CredentialInputUpdater) passwordProvider).updateCredential(realm, user, credentialInput);
}
Within CredentialInputUpdater.updateCredential make sure to update the local store in addition to the password in your database.
Now your user's passwords will be stored in Keycloak's local database / credential store and the built in password reset functionality should work as expected.
Is there a possibility to register a passward in keycloak for the user
just after the user is created in external database and then federated
to keycloak?
From the Keycloak Documentation itself:
By default, Keycloak will import users from LDAP into the local
Keycloak user database. This copy of the user is either synchronized
on demand, or through a periodic background task. The single exception
to this is the synchronization of passwords. Passwords are never
imported. Their validation is always delegated to the LDAP server. The
benefits of this approach is that all Keycloak features will work as
any extra per-user data that is needed can be stored locally. The
downside of this approach is that each time that a specific user is
queried for the first time, a corresponding Keycloak database insert
is performed.

Can Keycloack replace dap authentication?

Sorry but it doesn't accept "hi everyone "
I have several apps which are authenticated by ldap. can keycloack replace this authentication with ldap? and in this way I do not touch to the configuration Of applications ?
Thank you
You can read this article https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/user-federation/ldap.html
By default Keycloack copy your ldap data but you can choose keycloack use your ldap data :
By default, Keycloak will import users from LDAP into the local Keycloak user database. This copy of the user is either synchronized on demand, or through a periodic background task. The one exception to this is passwords. Passwords are not imported and password validation is delegated to the LDAP server. The benefits to this approach is that all Keycloak features will work as any extra per-user data that is needed can be stored locally. This approach also reduces load on the LDAP server as uncached users are loaded from the Keycloak database the 2nd time they are accessed. The only load your LDAP server will have is password validation. The downside to this approach is that when a user is first queried, this will require a Keycloak database insert. The import will also have to be synchronized with your LDAP server as needed.
Alternatively, you can choose not to import users into the Keycloak user database. In this case, the common user model that the Keycloak runtime uses is backed only by the LDAP server. This means that if LDAP doesn’t support a piece of data that a Keycloak feature needs that feature will not work. The benefit to this approach is that you do not have the overhead of importing and synchronizing a copy of the LDAP user into the Keycloak user database

Is there a way to map a role to linked server login in SQL Server

Couldn't find anything online about this, but I'd like to give a SQL Server role access to a linked server using a specific login to that server. I know you can assign a specific local login to a linked server login with sp_addlinkedsrvlogin but I'm not looking to do this for every login (nor am I looking for a script to do it for every login). I suppose there's some security reasons to prefer the use of an account, but I'd like to know if it's possible.
Not exactly possible, no.
To manage group-wise access, you're supposed to use the Be made using the login's current security context option (doc here). Then, if you're authenticating with Windows authentication, configure the login and user and security access on the remote server with a Windows group that your users are a member of. (If you were using SQL authentication, you'd need to have a login with an identical password on both servers to use this context.) Then you'd have to create the role on the remote server, assign permissions to that role, and assign the group to that role.
This is kind of a pain, but it does mean that no matter how your Windows users connect to the second server, they'll get the same access.

External authentication via LDAP

I am doing external authentication using LDAP. I have to authenticate a user via LDAP and allow the user to access many app servers. I want to know how to map all the ldap user ( users in ldap server Example:ldap://company1.local:389) with users in Database. I have created a external configuration object and assigned to a new http server with application level authentication. I dont want to store ldap user password in database. Do I have to create all users(same as in active directory) in database with some password and map them?
Yes, it's possible to configure ML to use external authentication via LDAP:
http://docs.marklogic.com/guide/security/external-auth

how to create LDAP user with restricted rights to LDAP

I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)