I'm trying to implement a custom credential-store (with custom CredentialStoreSpi implementation) to integrate with data-sources through credential-reference.
The idea is to use a vault service with rotating passwords, and, for now, when I start WildFly, it calls CredentialStoreSpi.retrieve() and initializes data-source with current password, but if I flush data-source and request a new connection there are no calls to .retrieve(). And if I rotate password, then, it fails to create connection with username/password error, and still do not call for a new password.
Looking in specs I see that data-source connection security has a config to some "Reauth Plugin Class Name", but I can't find any clues on what is that.
There is any way to change this behavior and force that any new connection should require password directly from credential-store?
Found this spec: https://docs.wildfly.org/20/wildscribe/subsystem/datasources/data-source/ExampleDS/index.html#attr-reauth-plugin-class-name
reauth-plugin-class-name The fully qualified class name of the reauthentication plugin implementation
Looking at web but find no documentation on this.
Anyone knows what is that? Could it help in this use case?
if the credential store is updated externally you have to do a reload of that credential store. Maybe calling the retrieve method or reloading the credential store in the server at a certain intervals might make sense
Related
Is there a way to configure a container so that for a certain user it allows creation of new objects, but denies deletion and modification of existing objects?
My case is that I provide a web service which receives and serves files using remote openstack swift storage and I want that in case of a credential compromise at the web service level, the person who gains access to those credentials would not be able to alter existing files.
To the best of my knowledge, I don't think it is possible to deny any user from deleting or updating existing objects of the same container, when one can upload objects using credentials.
But you can write a java API and expose it to the user to upload file and internally you can upload the file using the set of credentials. Do not expose the functions that the user is not supposed to do (delete/update etc). You can have all your creds and everything in the code (better to be encrypted). This way you may achieve what you want. But this is a work around.
I am trying to implement serverSessionTimeout in worklight server. I enabled serverSessionTimeout=5 and sso.cleanup.taskFrequencyInSeconds=5 in worklight.properties but no luck. We have user db entry for each user login. Ideally it should remove the user db entry once the session reached 5 minutes, but I am not able do clean the user db entry from server side. I appreciate if anybody help me on this.
As Iddo mentioned in the comments:
sso.cleanup.taskFrequencyInSeconds is related to an entirely different feature
serverSessionTimeout instructs the application server to invalidate sessions after the specified amount of time, but the actual cleanup can occur at the application server's discretion (see jaalger2's answer in this question
So in order to control the session, you need to setup the values to your liking. After that, simply let the application sever handle the memory threads.
Is there any particular reason why after the above you also need to access the database and delete rows from it? This should be handled automatically, not "manually".
This is related to Is there ReadOnly REST API key to a MongoLab database, or is it always ReadWrite and How does Mongolab REST API authenticate
I want to make it possible for unauthenticated users of my web app to create resources and share them. The created resource is an array of links ['link1', 'link2', 'link3'].
I'm looking at using MongoLabs directly from the client for this, which is possible through their REST api.
The problem though is that as far as I can see, if I do that, it would be impossible to prevent vandalists to clear out the entire collection rather easily.
Is this correct, and if so, is there a simple solution (without running a custom backend) to do something like this?
First off, you could create a "history", so if something goes wrong you can call on an easy command to restore records.
Secondly you might screen connected clients for abusive behavior; eg measure the number of delete or update commands in a certain timeset. If this get triggered you can call on your restoration process.
Note; i have no experience with MongoLabs whatsoever, but this - to me - would be a suitable safeguard in creating a public api.
I'm developing a system using NHibernate and PostgreSQL, with Npgsql data provider.
I need to get the logged in user in my system in a trigger in order to run an audit function.
Is there any way to set the user in the NHibernate session or to get it directly from the database?
Please help!
Here's a detailed explanation of how to get application-level user identity into triggers that I wrote a while ago. Essentially you can use a temporary table to store the user login or a custom GUC. Either way, your application must explicitly set that up when it creates a session so that it can be accessed later.
Personally I think you should usually be using PostgreSQL users and SET ROLE as explained here, but I realise that's not always an option.
I'm creating a iOS app that requires the user to log in at startup, and then uses those credentials to query 4-5 different services on a server over the course of the session.
The server (xyz) it self doesn't accept the credentials, but if the services that it provides are queried then they get accepted. For example https://xyz/service1 works, https://xyz doesn't.
Now what I'm wondering about is if there is anything that stands in the way of creating 4-5 NSURLProtectionSpace's at log in, one for each service on the server, and then use the corresponding protection space when use each service?
Or is there a better way of implementing something that could work in this situation?
All help would be appreciated.
Turns out that there is nothing that stands in the way of creating multiple NSURLProtectionSpace's since each is created for a separate url.