I have an Android app that connects to MFP server. I am using adapter to create a useridentity. So to change the useridentity I have used the following code.
WL.Server.setActiveUser("AuthRealm", null);
WL.Server.setActiveUser("AuthRealm", userIdentity);
Now my question is if my first userid is user1 and I have updated it to user2. Will the MFP database store both the userids or will it replace user1 by user2?
WL.Server.setActiveUser("AuthRealm", userIdentity); replaces the current user identity in the server.
Related
I am managing a Keycloak realm with only a single, fully-trusted external IdP added that is intended to be the default authentication mechanism for users.
I do not want to allow user to register, i.e. I want to manually create a local Keycloak user, and that user should then be allowed to link his external IdP account to the pre-existing Keycloak account, having the email address as common identifier. Users with access to the external IdP but without an existing Keycloak account should not be allowed to connect.
I tried the following First Broker Login settings, but whenever a user tries to login, he gets an error message (code: invalid_user_credentials).
Do you have any idea what my mistake might be?
Looks like they integrated this feature in version 4.5.0.
See automatic account link docs.
Basically you need to create a new flow and add 2 alternative executions:
Create User If Unique
Automatically Link Brokered Account
According to the doc: https://www.keycloak.org/docs/latest/server_admin/index.html#detect-existing-user-first-login-flow, you must create a new flow like this:
et voilà :)
As per this discussion:
https://keycloak.discourse.group/t/link-idp-to-existing-user/1094/5
It’s a bug in keycloak and they seem to be a reluctant to fix it for
whatever reason. I have very few users so I solved it by manually
querying the idp for the information keycloak uses and then copying it
into the relevant fields in the UI. So there is no sign up process for
my users I just make them myself. Obviously that’s a poor solution
though, what we really need is someone to take over that PR and
persuade the maintainers to merge it.
This is the PR: https://github.com/keycloak/keycloak/pull/6282
As it is described in this GitHub issue response the solution is to use a JavaScript authenticator that handles this.
In order to do so, you need to do the folowing:
Enable [custom authenticators using JavaScript in your server[(https://www.keycloak.org/docs/latest/server_installation/#profiles) by https://stackoverflow.com/a/63274532/550222creating a file profile.properties in your configuration directory that contains the following:
feature.scripts=enabled
Create the custom authenticator. You have to create a JAR file (essentially a ZIP file) with the following structure:
META-INF/keycloak-scripts.json
auth-user-must-exist.js
The content of the files are in this Gist, but I am including them here as well:
META-INF/keycloak-scripts.json:
{
"authenticators": [
{
"name": "User must exists",
"fileName": "auth-user-must-exists.js",
"description": "User must exists"
}
]
}
auth-user-must-exist.js:
AuthenticationFlowError = Java.type("org.keycloak.authentication.AuthenticationFlowError")
ServicesLogger = Java.type("org.keycloak.services.ServicesLogger")
AbstractIdpAuthenticator = Java.type("org.keycloak.authentication.authenticators.broker.AbstractIdpAuthenticator")
IdpCreateUserIfUniqueAuthenticator = Java.type("org.keycloak.authentication.authenticators.broker.IdpCreateUserIfUniqueAuthenticator")
var IdpUserMustExists = Java.extend(IdpCreateUserIfUniqueAuthenticator)
function authenticate(context) {
var auth = new IdpUserMustExists() {
authenticateImpl: function(context, serializedCtx, brokerContext) {
var parent = Java.super(auth)
var session = context.getSession()
var realm = context.getRealm()
var authSession = context.getAuthenticationSession()
if (authSession.getAuthNote(AbstractIdpAuthenticator.EXISTING_USER_INFO) != null) {
context.attempted()
return
}
var username = parent.getUsername(context, serializedCtx, brokerContext)
if (username == null) {
ServicesLogger.LOGGER.resetFlow(realm.isRegistrationEmailAsUsername() ? "Email" : "Username")
authSession.setAuthNote(AbstractIdpAuthenticator.ENFORCE_UPDATE_PROFILE, "true")
context.resetFlow()
return
}
var duplication = parent.checkExistingUser(context, username, serializedCtx, brokerContext)
if (duplication == null) {
LOG.info("user not found " + username)
context.failure(AuthenticationFlowError.INVALID_USER)
return
} else {
authSession.setAuthNote(AbstractIdpAuthenticator.EXISTING_USER_INFO, duplication.serialize())
context.attempted()
}
}
}
auth.authenticate(context)
}
Then, you can define as follows:
User Must Exist -> ALTERNATIVE
Automatically Set Existing User -> ALTERNATIVE
Honestly i am surprised by the keycloak auto creating behavior. I tried to add new Authentication flow as descibed here https://www.keycloak.org/docs/latest/server_admin/index.html#automatically-link-existing-first-login-flow
My flow :
1 - Create User If Unique [ALTERNATIVE]
2 - Automatically Link Brokered Account [ALTERNATIVE]
My use case : Authenticating users from Github ( Github as IDP )
Result : when a github user logon with an existing "username" keycloak links the github account to my local user ( based on his username ). I expected using his email instead of username.
I am debugging confirmation email flow when signing up a new User in Asp.Net Core web application with Identity Server 4.
Since I had already signed up with my actual email, to reuse it, I modified the UserName and Email in AspNetUsers table using SQL Update to some random value.
Now when I am signing up with the original email again. I am getting a duplicate user error
result = await _userManager.CreateAsync(user, model.Password);
I have already:
Cleared browser cache.
Closed local IIS Express
Restarted Visual Studio.
Used_userManager.DeleteAsync() after updating the UserName and Email back to original values but this gives an Microsoft.AspNetCore.Identity.IdentityError with description Optimistic concurrency failure, object has been modified.
On running this query on Sql Server
select * from INFORMATION_SCHEMA.COLUMNS where COLUMN_NAME in ( 'UserName' , 'Email')
I get the following:
I know that this is not a good practice to mess with backend, but this is development environment and I could continue my work with another email.
I would request readers to help in understanding how the User could be safely scorched to be able to reuse the email.
Appreciate your time
I agree with Kyle's comment and to further speed up your debug process you should note that if you use gmail to do this you can debug this process using one email.
from google/gmails perspective myaccount#gmail.com == my.acount#gmail.com == m.y.a.c.c.ount#gmail.com etc etc just try it out, google disregards all period characters in the email. you can enumerate/exhaust ~2^8 emails (in this example) if you just enumerate through the local-part of the e-mail address. but from your applications side, myaccount#gmail.com is not the same as my.account#gmail.com, ie they are different user accounts. Basically you can use one email to test out this feature of yours without having to delete the user.
Here is how I did it and finally got passed the pesky "concurrency failure" error message... This works in ASP.NET CORE 2.2
Obtain the user object through the FindByName method first.
Remove the user from their assigned Role (in this case I hard coded "Admin" because that is the role I'm interested in but fill in your own), then delete the user.
//Delete user.
//Obtain the user object through the FindByName method first.
//Remove the user from their assigned Role, then delete the user.
var userManager = serviceProvider.GetRequiredService<UserManager<ApplicationUser>>();
ApplicationUser delAppUser = new ApplicationUser
{
Email = "SomeEmailForindividualAdminUser",
UserName = "SomeUsernameindividualAdminUser"
};
Task <ApplicationUser> taskGetUserAppUser = userManager.FindByNameAsync(delAppUser.UserName);
taskGetUserAppUser.Wait();
Task<IdentityResult> taskRemoveFromRoleAppUser = userManager.RemoveFromRoleAsync(taskGetUserAppUser.Result, "Admin");
taskRemoveFromRoleAppUser.Wait();
Task<IdentityResult> taskDeleteAppUser = userManager.DeleteAsync(taskGetUserAppUser.Result);
taskDeleteAppUser.Wait();
With the help of the following API calls,
1. WL.Server.setActiveUser
2. WL.Server.getCurrentUserIdentity
We can create user session and get the user identity properties respectively.
I have a scenario where I want to update the properties[custom attributes] in the user identity object when the session is active.
I couldn't find an API which can do this task.
Is there any way/work-around available.
In general activated userIdentity is immutable. Try this, it might work
var userIdentity = WL.Server.getActiveUser("realm");
userIdentity[propName] = newValue;
WL.Server.setActiveUser("realm", null);
WL.Server.setActiveUser("realm", userIdentity);
I am trying to return a list of roles back to a mobile client device from the WL server
In the createIdentity method of my LoginModule I added the following code
HashMap<String, Object> customAttributes = new HashMap<String, Object>();
customAttributes.put("AuthenticationDate", new Date());
Set<String> groups = new HashSet<String>();
groups.add("Managers");
groups.add("Users");
UserIdentity identity = new UserIdentity(loginModule, USERNAME, "Fred Flintstone", groups, customAttributes, PASSWORD);
The display Name "Fred Flintstone" gets returned to the mobile device, the custom attributes get returned, but the group information seems to get lost somewhere.
I get the following displayed in the mobile device logs
"BasicAuthRealm":{"userId":"user1","attributes":{"AuthenticationDate":"Thu Nov 14 22:39:35 EST 2013"},"isUserAuthenticated":1,"displayName":"Fred Flintstone"},"WL-Authentication-Success":{"BasicAuthRealm":{"userId":"user1","attributes":{"AuthenticationDate":"Thu Nov 14 22:39:35 EST 2013"},"isUserAuthenticated":1,"displayName":"Fred Flintstone"}},
I am running WL 6.0.0.1 Enterprise edition and running against a Liberty server v8.5.5.0
Any ideas?
The groups object is not sent back to the client after the user successfully authenticates. The only parts of the UserIdentity object that are sent back are the name, displayName, and the attributes. I do not know the reason that the groups aren't sent back. Perhaps the objects purpose was only meant for the server and was never intended to be used by the client.
The unfortunate but easy workaround is to add any information you need to know about your group to your attributes object.
I'm new to meteor and am stuck on registering a login handler that lets me use the password to authenticate the user.
I'm working off the code from http://meteorhacks.com
The server side code is as follows:
Accounts.registerLoginHandler(function(loginRequest) {
var userId = null;
var user = Meteor.users.findOne({'emails.address': loginRequest.email, password: loginRequest.password, 'proile.type': loginRequest.type});
if(user) {
userId = user._id;
}
return { id: userId}
This works fine if I take out the password field and just use the email and type ones. How do I get this working with the password as well?
Bottom line, you can't directly search via the plaintext password. You need to verify the password via SRP which is a little tricky as there isn't any documentation on it. Luckily Meteor is open source! A good start is at the accounts-password : https://github.com/meteor/meteor/blob/master/packages/accounts-password/password_server.js
There already is a package that can do password logins for you (the one the above file is from). You can add it to your project via meteor add accounts-password.
Then you could login with Meteor.loginWithPassword