I am trying something dirty on keycloak. I have a realm level 90 days password expiry for user credentials, but I am trying to find an way to go around that for a few users of my choosing (my own service accounts).
I am able to work on the DB to update the creation date of the credentials I want a not-expired timestam, no problem.
I still have an issue with user with already expired passwords (I can update you guys later if this works with non-expired - I am still testing).
Lets say user A has an expired password, but hasnt tried to use it since it expired:
I can see that both in the UI or in the user_required_action DB Table: there is no req_action in there.
I update the credential created_date to Now()
If I try to get a token: I have the regular expired password error "Account not fully setup"
Now I can see a Required action both in the UI and int the DB
I delete the req_action from the DB and I refesh the UI: the required actin is still there. And if I try to get a token, i get a "Account not fully setup" error again.
Now, if I delete the reuqired action from the UI. Then I am able to get a token.
So in some ways, deleting a user action from the DB only is not enough.
Would anyone have any suggestions?
Is there a cache, is the action still referecnes somewhere in another table?
PS: I know I am not supposed to user "users" for service accounts! I need to get around to change that. Please dont judge!
Related
As the title says, I'm developing a Custom User Storage Provider (here forth SPI) with Keycloak 15.0.2.
I’m having trouble sorting an issue where the very first access token that is issued, does not match the expected format (is missing some fields) but also seems to be issued for a different user, if I am to judge only based on the sub field of the AccessToken generated.
To ease reproduction of the issue, you can find my repository on Github here with a complete sample FE and BE along with the keycloak configuration. I also included samples of the result tokens, jwt.io links and logs on LOGS.md file on the repo.
I think I understand why this mismatch is happening, though.
Due to the fact that I start with an empty collection of users on keycloak, I need to create the users on their first login. All I have to start with is their email address which is input on the login screen.
With this information, I setup a “temporary” Federated User until I get the user data from the “real” IDP on the isValid method (where the user actually logs-in into the third party IDP) and then get his details, which are then used to fill a more complete FederatedUser profile and store it on the userLocalStorage.
It's basically this logic (it's all also explained in comments in the repo's code):
Create an adapter/model based solely on the email from the login form to be used temporarily.
Proceed with normal operation.
Then on the isValid() method:
login the user through the REST call to the backend and get the JSESSION token
on a separate call, call the Current-User REST endpoint to get user details and map them to a Dto object
create a new adapter, based on the Dto object (which already contains all the user details like name, phoneNumber, etc) and from that, add to storage as a ksession.userLocalStorage().addUser() user and enrich with custom attributes (to later be mapped into the AccessToken)
when (and if) added, clean cache with ksession.userCache().clear()
Proceed with normal operation
However, I think that the ID/model of that first temporary user is the one that is actually being used during the issuance of the first AccessToken that is generated and is being cached somehow on some other class which then generates the AccessToken with missing information/not the correct user model.
When I reload the page (forcing it to go through the login flow again), I then get the correct AccessToken with all the fields I expected the first one to have. I also noticed that the sub of the tokens are different, and this is what leads me to this conclusion.
Does this flow/conclusion seem correct to you?
And more importantly, how can I fix this?
I have no way of getting all the user data at first or a way to import it (ideally, I didn’t even wanted to Federate, just some ReadOnly data would have been enough if I could modify the AbstractUserAdapter attributes).
Can I somehow access the CredentialInput outside the isValid method?
That’s the only way I’d have to grab all the user data since the beginning.
I’d really appreciate any help you could spare. The reproduction code is just a clone/docker up away and will replicate the issue perfectly.
Please help me figure out how to make sure the token get properly set/issued the first time around
Thanks
I using back4app service and as admin I would like to fetch PFUser records and delete some of them if needed.
Currently I am getting error:
User cannot be deleted unless they have been authenticated.
I logged in as a PFUser. Is are any possibilities to do it via masterKey or smth like this?
The best option I see here is to use cloud code as you would not want to give authenticated users permission to delete other users.
So basically you would have to write a Cloud code function where you retrieve users and delete them.
Have a look at this guide below
https://help.back4app.com/hc/en-us/articles/360045500871-How-to-update-a-user-
Working on a new app and have some testers using it. One of them forgot their password and my partner made a mistake and changed the password for that user to something in plaintext from mLab. We usually make password changes (for now, until we build the password reset logic) in parse dashboard directly: enter in a password in plaintext, it's hashed automatically.
When we try to load the User collection in Parse Dashboard to make the change to the password and hash it accordingly, the User collection doesn't load. The other collections load just fine though.
I've tried updating my parse dashboard version since I was running a slightly older version, but that didn't work either.
Any advice on a fix?
I'm creating a simple React-Redux Blog website. So these days i was searching and searching how to do user authentication, and i couldn't find nothing helpful, there were only auth with JWT token, which for me at this moment is really hard to understand so i came to idea, which i don't know is it good or no, so i want to hear more about it.
WHY am i doing this? Because i already made more than half website, but made mistake at beginning because i did simpliest possible auth with local storage, which is really bad...
So idea is to user register with Firebase with email and password.
Then will be created a user in Mongo with unique email(which i will use as ID), and empty other data like username, about section etc, which are not required and which user enters later. So Firebase is only for user login and sign up...
After login i am checking if user is authorized with checking if email in state provided by redux is empty... If is some value in it then i will allow user to do some stuff around...
So i am wondering how i'm gonna deploy it on web and will it work... Any suggestion?
Our application is using Symfony 2.0 and MongoDB with FOSUserBundle for user management.
Client wants to prevent login with the same username from different device at the same time in their application.
Our idea is to invalidate/delete all other sessions for the same user when the successful login occurs.
The problem is, that we cannot save session in DB, because Mongo Session handler was added later in the version 2.1.
The only solution we come up with is to iterate over the session files saved in file-system and check if the username of the user is saved in that file. If that is true, we just delete the file and login session on other locations are terminated. Of course we have to check that we don't delete the current session also.
Does anyone have a better idea how the problem could be solved?
If not, are there any hidden traps that we should know about?
You could add an IP address column to the user entity that stores the current user's IP upon login. On each page load (via an event listener), you could check the IP stored in the DB against the IP of the person requesting the page. If the IP in the DB doesn't match the current user's IP (someone logged in from another location), log them out.
To take it a step further, via ajax, you could make a call to the server every X seconds that performs the same type of check, and do a redirect to log the user out if the ajax request returns a bad match.