Trying to automate the manual process of updating a user's app id and password for One Login. When the user gets created, we have to manually go to user > applications > select app > update ID and password.
Is there API I could use to update the user's app ID and password? I could not find any.
There's two APIs to set a user's password:
https://developers.onelogin.com/api-docs/1/users/set-password-in-cleartext
https://developers.onelogin.com/api-docs/1/users/set-password-using-sha-256
Depending on where your user is mastered, you might have to adhere to password complexity rules not maintained in Onelogin, so prepare for that in your code.
Why would you change the value set for the user's Subject ( NameID ) in the app ? Is your data inconsistent so you can't set a rule for that in the standard app configuration ?
The new app API might do that for you, but if you're needing to do that process on a consistent basis, then you should be doing some house keeping in your data source.
https://developers.onelogin.com/api-docs/1/apps/update-app
What's the default password of 'system' in Jhipster? I only have seen the default passwords for admin and user but not the default password for the system. I could not find it in the jhipster docs as well. Thanks.
I'm fairly sure JHipster don't provide this for you. If you really want to gain access to the system account then just create a new user with the password you want. Copy the hashed password for the new user in the database and copy it into the system password part of the .ddl file with the default JHipster accounts defined in it and then rebuild your database.
Given I have a existing project and I want to add an external GitLab user to the project.
The user can enter his/her GitLab username (and additional fields if needed) in a UI.
What is the best practice to verify that the user is valid and that the user is the real owner of the entered account over the GitLab API?
This should also support external login methods (GitHub, ...).
I have followed Custom Authentication Web Service link to customize authentication.
But Liferay is still checking whether the same user email id is configured in the liferay db or not. If its not, it is saying that authetication failed.
I do not want to keep any user information in the liferay db. Do any one know how to do that?
Regards
Vishal G
Create dummy users for your real users with fake data. Liferay requires some sort of Liferay user in the database to function correctly. You can create one dummy user for each real user or one dummy user for all your users depending on your needs.
When supporting a new web app in an enterprise environment, it is often necessary to log in as a specific user in order to diagnose a real or perceived problem they are having. Two opposing issues apply here:
Best practice is to use hashed or encrypted passwords, not clear text. Sometimes, there is a third-party SSO (single sign-on) in the middle. There is no way to retrieve the user's password. Unless the user provides it (not encouraged), there is no way to log in as that user.
Many web app's have personalization and complex authorization. Different users have different roles (admin, manager, user) with different permissions. Sometimes users can only see their data -- their customers or tasks. Some users have read-only access, while others can edit. So, each user's view of the web app is unique.
Assume that in an enterprise environment, it isn't feasible to go to the user's desk, or to connect directly to their machine.
How do you handle this situation?
Edit: I want to reiterate that in a large financial institution or typical Fortune 500 company with hundreds of thousands of employees all of the country, and around the world, it is not possible for a mere developer in some IT unit to be able to directly access a user's machine. Some of those are public-facing web apps used by customers (such as online banking and stock trading). And, many of those are intranet applications rely on Active Directory or an SSO, meaning that user credentials are the same for many applications. I do thank you all for your suggestions; some may be highly useful in other kinds of environments.
A number of these ideas inconvenience the user, either by forcing them to change their password, or by occupying their desktop for your debugging session.
Markc's idea is the best: augment your authentication logic to allow superusers to log in as a particular user by supplying not the user's credentials, but the user's name plus their superuser credentials.
I've done it like this in the past (pseudo-ish python):
if is_user_authenticated(username, userpassword):
login the user
else if ':' in userpassword:
supername, superpassword = userpassword.split(':')
if is_superuser_authenticated(supername, superpassword):
login the user
In other words, if the username and password don't authenticate, if the password has a colon, then it's actually the admin username and admin password joined by a colon, so login as the username if they are the right admin username and password.
This means you can login as the user without knowing their secrets, and without inconveniencing them.
For our web applications we use a process that for lack of a better term is defined as 'hijacking' a user's account.
Basically, administrators can 'hijack' a user's account with a simple button click. In the code, you simply use a unique identifier (user id works in a less secure environment) that then establishes the necessary credentials in the session so that they can then work within that user's profile. For a more secure environment you could use a unique hash for each user.
In order to ensure that this hijack method is secure, it always first verifies that the request is being made by an authenticated administrator with the appropriate rights. Because of this it becomes necessary for either the administrator's session to be hijacked or for their authentication credentials to be captured in order for someone to ever exploit the hijack function within the application.
I had 4 ideas. While I was typing 3 of them were already suggested (so I upvoted them)
Variant on idea 3 - impersonation:
To make this as "identical as possible" to a normal login with minimal code changes, you might add the ability to impersonate directly at login by supplying Admin credentials plus an alternate username, e.g. login as Admin:user, adminpassword. The system would treat this exactly as logging in as user with userpassword.
Idea 4: Can you access the password store? If so, temporarily replace the user's hash with the hash of a known password. (the passwords are often stored online in a database. A SQL Query tool can do the swaps )
An administrator should be able to change a user's password. Change the password for the user to something you know. You can then log in as that user.
Tell the user to reset his/her password after you are done debugging.
Usually by some sort of remote control software that can be used to view their desktop. If they're on a Windows terminal server, then the built in admin tools can be used for that. Otherwise I'd use something like VNC across an internal network, or an external service like LogMeIn (http://www.logmein.com/).
Could you have a testing environment where there is a regular cut of live data copied to (obviously sanitised to meet any security or data protection issues). A user similar in setup to the one having trouble could be used to troubleshoot or indeed the very user if this is allowed.
Use a remote desktop client as mentioned in other answers, but again this may not be practical for you. If you have these rights within the domain, I have heard of error handling even doing a screenscrape and including this in logs! but this sounds a little odd to me.
Could you have an admin tool to clone a user into a demo account?
The solution we have used in our web apps is to have the authN/authZ return the desired user as the effective user. We do this by having an admin feature to setup a masquerade, and then when we ask for the currently logged in user (current_user), we handle the masquerade:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user