I've searched all of google and stackoverflow for this, but with no success. I'm starting to feel the simple answer to this question is "no", but I haven't been able to confirm this either.
Is there a way to limit apache to 1 session per authenticated user?
Say I'm logged in as admin1 (using .htaccess and .htpasswd). Is there a way to stop another user from also logging in as admin1 as long as I am connected?
Basic authentication by itself has no concept of a user session, and the HTTP protocol is stateless without such a concept. As such, there is no concept of "connected". You might however be able to use mod_auth_form - http://httpd.apache.org/docs/current/mod/mod_auth_form.html - to provide a session-backed basic authentication. I don't know that there is any provision for limiting a single session per login though. Chances are you need to do this in the application layer.
Related
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
I am currently recording a web with Login LDAP that means I need to input username and password in popup authentication (screenshot attached).
After I am done recording, I play back the script, and it always failed.
And I followed tutorial from https://www.blazemeter.com/blog/windows-authentication-apache-jmeter but it still failed.
Here is my Test Plan:
Here is HTTP Authorization Manager setting:
Please help.
Thanks,
Rio
If you really "followed the tutorial" you should know what is your authentication type challenge, the choice is in:
Basic Access
NTLM
Kerberos
Your setup is wrong for any of the types as you should have either base url or domain or domain+realm+appropriate configuration in jaas.conf and krb5.conf files.
I don't think sending one request is sufficient for simulating log in process, real users do the following:
open login page (at least 1 request)
type credentials (you need to mimic the time required to type using Timers)
perform login (another at least 2 request)
You may also need to perform correlation of dynamic parameters (if any), check out How to Handle Correlation in JMeter to learn more about the concept / implementation
Your approach of AJAX requests simulation is wrong, as per the definition AJAX requests are Asynchronous, to wit real browsers execute them at the same time while in your setup they are sequential. So consider placing the AJAX calls under the Parallel Controller
i have a scenario running with an own CALDAV-server and CALDAV-clients like (iOS-calendar, mac-Calendar, Android sync adapter, Thunderbird/Lightning, Outlook Sync, ...)
The authentication so far works via basic auth (https and the "Authentication"-Header).
The CALDAV-clients store the user/password in their configuration.
So far so good, but the issue comes now once the password of the user/account either gets changed, reset, expired, etc.
The server has a restrictive password policy enforced, which locks the account after x failed attempts (e.g. 10).
What is happening now obviously is, that once the CALDAV-client configuration was not updated it continues to use an old password.
The server responds with an 401 not authorized - ok, thats fine apparently again.
But the Clients still continue to use the outdated password. It would be nicer to stop polling and present the user with a dialog that his credentials are not valid anymore. But the clients are out of my control so nothing can be directly done here.
The result: after 2-3 iterations (as most clients tries multiple request in one sync iteration) the account on the server of the user is locked due to too many failed login attempts.
That is not nice. The issue seems to be generic and known as "stale passwords".
A solution could only be a better client handling (out of scope here) or a oAuth-token handling. But i was not able to find anything that standard CALDAV-clients supports this. Only google calendar seems to enforce an oAuth2 authorization before allowing CALDAV communication.
So the question is, is there a good way to improve the bad experience of locked accounts?
Some special 401 response which tells the clients to forget the password or not using it again?
constructive feedback highly welcome.
Edit:
for macOS and ios calendar i found a strange behavior (bug) causing and/or enforcing the described situation.
A standard 401 response will cause the clients to bring up the password dialog as expected and described above. The clients stop polling until a new password is entered - as desired.
In my case the 401 response body contained an inline base 64 image (img src="data..."):
This doesnt lead to a password renewal dialog! Just a "something goes wrong" error state.
The clients are continuing to poll! Locking the accounts after some tries ;(
A solution for this problem than will be to remove the inline image but for me it sounds like a bug that an inline image in the 401 response provokes a different behavior on the client.
Some special 401 response which tells the clients to forget the password or not using it again?
Well, 401 is that response. If the client receives a 401 it knows the the login/password combination it provided doesn't work anymore, and shouldn't retry with the same. Obviously the clients don't do this, partially because:
On the other side your servers x-failed-attempts locking doesn't work with stateless protocols for obvious reasons. HTTP doesn't have that feature builtin. Locking the account is a side effect a client doesn't have to expect when running idempotent HTTP requests.
Assume the client is downloading 10 batches of items concurrently. If the credentials invalidate during this, the account would immediately be locked :-)
Summary: You can't use basic auth naively with backends that lock accounts after n-tries.
Google and iCloud both use token based auth schemes (Google OAuth, iCloud a proprietary one). You can't expect those to work in other clients. E.g. while the Apple clients support OAuth for Google, I don't think they support that for other account types.
So what can you do
I'm reading your question so that you own the account server and that the account locking is intentional and desired. (I.e. it is not a side effect of a different (e.g. SSO) backend system you reach out to.)
I think in this case it should be reasonable to rework your account system to allow unlimited login attempts with just the old password.
The lock-after-n-attempts measure is to protect against people trying different passwords. In your case it is always the same and as a bonus it also matches the old password.
There are a lot of different variations of this approach.
I would like to understand something please.
I have an application based on oAuth2 with Google Accounts.
So, teh first time I connect to this website, I am redirected to the authentication page on Google domain. So I type my email and password and I dont check "trusted computer" (or "remember me", I dont remember the exact term).
The thing is if I reboot my computer or even delete my cookie (but not my history (tested with Chrome on Android phone), I am not prompted again for the authentication and I have directly access to the application.
I would like to understand why ?
If somebody can explain it to me that should be great !
Thank you
You can actually force re-authentication in the Google OAuth api by passing &max_auth_age=0 to the auth URL.
Source:
Use the PAPE extension for further control of user authentication (optional)
Use the max_auth_age parameter in the PAPE extension to ensure that the login session of the user at Google is recent. You may also specify max_auth_age=0 to force a password reprompt.
https://developers.google.com/accounts/docs/OpenID
It's a bit confusing because they talk about OpenID, but I'm doing this successfully with Google's provided OAuth2 libs.
The Google OAuth 2 API really doesn't give you a way to force re-authentication. Lots of people have asked for this capability though, and maybe we should provide it.
It's hard to say, since it depends on what the flow was that as being executed.
Generally (with oauth) you weren't being prompted for authentication. You were being prompted for authorisation. Once you've authorised, you won't be prompted again, provided of course that the browser/google have some sort of session in existence which identifies the user.
When you say "delete my cookie", which cookie?
Yo can try going to this page https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en_GB and revoke the permission. That should then cause a repeat prompt.
I'm using an external Node.js module, everyauth, to handle my LinkedIn API authentication. I'm not yet positive if this is a problem with the way my module handles their API, or some other API issue itself.
Basically, after a user has already granted access, LinkedIn nevertheless continues to ask whether to continue to grant access. I know this is not standard because I've seen a different user flow in other applications.
Here's an example of what happens:
You can see I granted access on Jan 11th, but this was taken on Jan 13th. Why must I re-auth!?
Do you have any idea what is causing this? I dove into the relevant LinkedIn module code for everyauth but nothing in that application flow caught my eye as the problem.
Modify the script to send them to https://www.linkedin.com/uas/oauth/authenticate instead of
https://www.linkedin.com/uas/oauth/authorize.
That will cause LinkedIn to automatically redirect them back to your site.
See more at https://developer.linkedin.com/documents/linkedins-oauth-details
If you are using the JavaScript API (which it looks like everyauth uses), then it is likely that the OAuth tokens that LinkedIn stores in the browser have become 'stale'. To ensure that the user is the correct user, the browser tokens expire after ~30 minutes.
That being said, if the session is still fresh and the authorize value is set to true, you should be able to bypass the screen you are seeing.
https://developer.linkedin.com/documents/overview