I'm trying to implement simple password-based authentication for a web application written using the Happstack framework. My user presents an ID and password, which I hash using bcrypt and check against by database. If the hashed password is in the database for that ID, the user is thereby authenticated.
Once I've authenticated the nice user, I would like then to issue a session cookie which marks that user has being logged in for the duration of the session. (I am not trying to implement a "persistent", "remember me" sort of cookie; I am just trying to find out if the user is logged in for the session.)
Is the presence of the session cookie alone sufficient to authenticate the user?
If not, what other information is needed? I could store the cookie's (hashed) value in my database, but at this point, I don't see how what I would be doing would be much different from a persistent login cookie.
In short, is it possible for me to use a session cookie to identify an authenticated user, and if so, how should it be done?
(I have been able to learn how and why to mark the session cookie as "secure" and "HTTP only", but I can't figure out what to do with the darn thing!)
You can use happstack-authenticate for an existing solution to password logins. If you still want to roll your own however you'll want the happstack-clientsession package for session cookies that the user can't read or write. A normal cookie marked "secure" only means it only works over HTTPS, but the user can still both read and write the cookie. With clientsession the cookie will be encrypted with a server-side key. You can use clientsession both for "remember me" and session logins; it simply depends on what you set the sessionCookieLife to. The default if you use mkSessionConf is Session which is what you want.
Related
I have a web application with singe factor authorization and now have implemented two-factor authorization. I am using the Microsoft Identity for the log-in. The problem is - so far we have used a cookie to remember the user while providing the username and password. Say that as 'signglefactorcookie'. Now on the authenticator application authorization page(TFA), I have added another cookie for the remember me option. Say that as 'twofactorcookie'. Now how can I make my client request for both cookies when I use the below code?
// Check whether there is a valid session or persistent cookie
if(this.User.Identity.IsAuthenticated){
// Move to a landing page
}
Problem scenario
Now the problem is, if I log in to the single-factor authentication page with the correct user name and password and land at the two-factor authentication page.
Open a new tab and try to access the home page getting success since there is a single factor cookie that is recognized which makes the user authorized.
How can I make it in a standard way?
I can not seem to find a SIMPLE answer to the question on how to persist OAuth2 authentication... Let's take Google+ OAuth2 API as an example.
User goes to page
User is not authenticated, and gets redirected to authentication page where he logs in
User logs in successfully and authorises my app
User gets redirect to specified (by me) URI with Authorisation Code
I use authorisation code to obtain a token in order to submit queries in the name of the user
All is good and well. My question is: how do you SECURELY know at step 2 that the user visiting the page is already logged in, without having to go through the whole process of redirecting him to all these pages.
I assume storing the Authorisation Code retrieved at step 4 in a cookie is not an option.
All of this will happen in a server-side (Go - if that matters) application.
Any help is much appreciated... I need a simple solution.
Thank you!
use server-side sessions to store any authentication state or even access tokens if you need them.
one solution is to use a database for session store (an encrypted cookie holds the session id)
and another is to use cookie sessions (encrypted cookies that hold the session data).
using encrypted cookies that only the server is able to decrypt should be safe enough.
I am using WSO2 Identity Server 4.1.0 to perform basic authentication. It is possible to call the AuthenticationAdmin webservice, which contains a 'loginWithRememberMeOption'. The user will then obtain a 'rememberMeCookie', with which he can log in, even if his session (JSESSION) has expired.
I have learned that the loginWithRememberMeOption also has a timeout: 7 days, and that this time cannot be modified: WSO2 Authentication, adding/modifing timeout to the RememberMe cookie
The AuthenticationAdmin service also provides a 'logout' operation. Unfortunately, this operation will only invalidate the session. So if a user has a rememeberMeCookie, he will still be able to login: WSO2 AuthenticationAdmin Logout
The question is, how do I logout a user that has obtained a rememeberMeCookie? Preferably using the AuthenticationAdmin?
As I understand there is no direct way to logout a user with a remember me cookie.
I went through the code. Once you login with remember me option, a UUID is generated. Refer org.wso2.carbon.core.services.authentication.AuthenticationAdmin.loginWithRememberMeOption(String, String, String) method in AuthenticationAdmin
The cookie is then saved in database. When you login with remember me cookie, the cookie is checked from the user store. Refer org.wso2.carbon.user.api.UserStoreManager.isValidRememberMeToken(String, String). You can check the JDBC implementation.
So, in order to logout, you might have to clear the cookie from the user store.
Please report a JIRA issue, if you think it might be useful to add a method to clear the cookie.
I'm trying to implement a way to actually logout from my application that is using the Valence API. I can obviously clear the session on my end, but is there a way through the API to actually log out of the Desire2Learn site as well? I've looked through the docs and didn't see anything.
No, there is currently no route to explicitly log out, or log in. You can, however, use the Valence auth process to generate credentials for a new user. What you need to do in that case is use a browser to interact with the user that doesn't have an open session with the LMS: as long as the LMS thinks that the browser doing the user part of the authentication has an open session, it will pass back the user credentials for that user instead of asking the user to re-authenticate.
Typically an inactive session with the LMS expires after a short time and then the LMS will force the user to re-authenticate if your app initiates the auth process.
I am setting up my own CAS. A authentication handler was written and username/password are authenticated against a MySQL db. I also add signup page and related logic.
Now I would like to let user automatically log on when he/she has registered as a user. How to achieve this?
The comment above is incorrect - CAS clients do not have access to the cookie, only the CAS Server does - CAS is not a shared-cookie protocol.
If you only have a single site, you can just create a session on the client, using the standard mechanisms for Java, Ruby, whatever platform you're using.
If you want to create an SSO session for login to multiple applications, basically you need to:
Create a SSO session (via the CAS server)
Redirect to the CAS Server
Have the user redirected back to your application.
To accomplish the first one, you likely will want to modify the CAS LoginFlow to allow you to authenticate the user, either via one-time token or a similar mechanism.
Here is my implementation. The idea is borrowed from class org.jasig.cas.web.flow.AuthenticationViaFormAction.
In my web controller handling unlock request which is often from a registration email of a new user.
String oneTimeAuthToken = this.userManager.generateOneTimeAuthToken(userEmail);
UsernamePasswordCredentials credentials = new UsernamePasswordCredentials();
credentials.setUsername(userEmail);
credentials.setPassword(oneTimeAuthToken);
String tgt = centralAuthenticationService.createTicketGrantingTicket(credentials);
ticketGrantingTicketCookieGenerator.addCookie(request, response, tgt);
log.debug("Current user was unlocked and logged in.");
The fundamentals behind this is to create a temp password-like token to authenticate. Of course, userManager should clear this token automatically once authentication is successful.
Hope this is clear. Let me know if you observe anything wrong.