Question
How can a webform explicitly tell the browser or password manager which system a username and password are to be remembered for?
Context
I design an authentication system that offers multiple identity providers, and most of our users have accounts on more than one identity provider (IDP). These IDPs are on different subdomains (but I'd rather not limit answers to that, if possible). A username is only unique within an IDP, not across all IDPs.
This has led to some usability problems
The password manager may save a username and password as the primary domain (example.com) or inappropriate domains (subdomain1.example.com) instead of the appropriate secondary domain (subdomain4.example.com). This choice is then impossible to differentiate from other options sharing the same username.
It also leads to second-order usability problems described in How can I tell a password manager which username/password to use?.
The password manager may give options of which password to overwrite but suggest only one username and password out of many, and the wrong one at that, requiring the user to search through the password store for the matching one.
When a user changes their password, the password manager may overwrite the wrong password in its store.
Values saved by a password manager are related to field names. If each of these particular IdPs had a different password field name, then after one annoying hurdle (manually adding different password field values for differing IdPs), the single password manager entry would fill all the fields correctly leading to a simpler user experience.
Related
I have keycloak instance (version 16) with one realm and two different clients.
The first client works with Open ID Connect Identity provider. It also works with public Access Type and with SSO and 2FA.
The second client works with a Custom module added from User Federation where 2FA is not possible to be used because the calls for authentication are mainly programmatically. Also, this client works with confidential Access Type.
The problem is that each client has a different external database with users, but the usernames in these databases are not unique.
And if I try to log in with the second client it works but after that, if I try to log in with the first client I can't, and vice versa. (in both clients username "notUniqueUser#email.com" is used)
The error message in this case is:
User with username notUniqueUser#email.com already exists. How do you want to continue?
“Review profile”
“Add to existing account”
Is it possible for these two clients to work both properly at the same time, when I do not have unique usernames and how should I configure it? (I find that is possible to have same email addresses but I can't find anything for usernames)
Maybe some kind of force authentication will be OK, and when the user "notUniqueUser#email.com" is already logged with the first client and I try to log in with the second, the session from the first one to be deleted and vice versa.
Depending on how your IDPs are configured you can try the following:
go to your realm
then to the IDP configuration in question
switch to Mappers
Click on Create
As a mapper type select Username teamplate Importer
in the template field and something that will make the username unique for example ${CLAIM.preferred_username}_<The Name of the IDP>
For example, if a username named 'user' logins from both 'IDP1' and 'IDP2' it will be imported into the Keycloak DB as 'user_IDP1' and 'user_IDP2', respectively.
We're using Keycloak 12 for authentication in our portal and there are two different types of users:
Internal users (read from our internal LDAP)
External users (stored in Keycloak but without being synced with the LDAP)
We'd now like to use the "Forget Password" feature provided by Keycloak. After having configured the feature and the mail server, this works fine out-of-the-box.
However we'd like to restrict the "Forget Password" feature to all users which belong to (2), i.e. the internal users. These users are not allowed updating their password via Keycloak as this is done by another mechanism.
I couldn't find any information in the documentation so far if this is possible at all?
The Keycloak Forgot Password feature is applied at the Realm level, hence applied to all the users belonging to the Realm. For Keycloak, the LDAP is just an external storage with users to authenticate against. Consequently, out of the box, there is no way (as far as I know) for the Forgot Password to only be enabled to certain users within the Realm.
Even if it would be possible IMO it would not be a very user-friendly feature, since when one activates such a feature a new link will be shown to the users on the login page in case they have forgotten their passwords. So if a user from the LDAP would click on it, it would display an error or something?!
Alternatively, you can configure the LDAP of the so-called internal users in another Realm than the one with the Forgot Password enabled. And then configure the newly created realm to be an external Identity Provider, which the users could explicitly authenticate against it. So in practice, the users would lend in the normal login page, the external users could login normally, and would have the Forgot Password option enabled. The internal users would explicitly click on the external IDP to authenticate themselves. Log in using the external IDP would be a similar user-experience as log in to the normal login page, however, the Forgot Password option would not be shown.
You can see an example such configuration here.
I want to do the following
User signs up to IOS app and provides username and password
Make a server call and store password in server database
When user logs in in the future, retrieve that password and check against the password that the user entered.
How can I do this in the most secure way possible? I was thinking of encrypting the password when storing in the db. When the user logsin, use the same encryption algorithm and compare against the db encrypted password.
NEVER ever store user credentials in encrypted (reversible) form. Currently best known way for checking user credentials is slow salted hash
for what and why please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
However, don’t try to invent your own algorithm for repeated hashing.
Choose one of these three well-known ones: PBKDF2, bcrypt or scrypt.
As already commented you may outsource the user authentication to some reliable service (google, fb, aws cognito, ibm appid,...)
Have you tried looking into databases? I know that Firebase has an authentication component of their database for ios development, and you might want to try to look into it or other databases. Check out firebase at: https://firebase.google.com/
Is it save to create backend user with an empty password?
For example the _cli_lowlevel backend user or a backend user editor-test, which I only use for testing purposes via the "Switch to user" feature.
usually a cli_* user should have no rights to access anything in the BE (non admin user, with no mount-points). it is used to execute TYPO3 by command line. if anyone can get access to a shell he can execute commands more dangerous than a simple BE-access. e.g. he can open access to the install-tool and create an admin-user. or use mysql-cli to set passwords to any given user.
normally you can not create BE-users without password as the form for BE-users requires a not empty password field. as you probably use salted and hashed passwords even a simple password can not be decrypted (so a brute force attack may find the password quickly). so the best way would be a long random password which you might forget the next moment.
There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.