I seem to have coded myself into a corner. First let me tell you what my end goal is: I have a GWT app that will have features available to users who are not logged in, and other features only available to authenticated users. When an unauthenticated user clicks on something that requires authentication, I would like a login box to pop up in a modal window, and ask the user to authenticate. (if this is unclear go to digg.com and try to "digg" a story without being logged in, you'll see what I mean)
I have code to add a user and save their username and password (hashed with jBCrypt). I also have an RPC that accepts a username and password and can validate if the password is correct.
My problem is validating the session. I can get the JSESSIONID, but that's the part where I get lost. How do I associate the user's ID with that session, and how do I check that it's still valid?
I know glassfish can manage the session, users & roles for me, but I don't know how to make that work smoothly with GWT. Are there any examples with GWT and authenticating users in a Java EE environment? I've been googling for hours and I've come up with nothing.
Your question is a bit confusing, since I have the impression that you are going in 2 directions at the same time :-).
If you want to use Java EE authentication then you will need to use some plain HTML pages that you can configure in the web.xml. Using RequestBuilder you can actually do the interaction with these pages from GWT code (as we do).
If you want to know more about the user that is authenticated then use the Principal object that comes with the HttpServletRequest. The Principal object has a name attribute.
Using Java EE authentication is very limiting so in most cases we tend to implement our own instead.
Related
I'm trying to get my standalone webapplication to use my Liferay 6.2 as "user store". That means I want the user to log in to Liferay and then be able to move on to another application with some credentials and user specific information passed as well. Moving on and passing information is already working, the issue I'm having right now is making sure the user-object that is passed on is the user that is actually logged in right now.
I use the LFR_SESSION_STATE_ cookie do determine the logged in user. But when I log in again with another user I get a second cookie with a different user-id. So now I need to make sure that I'm passing the correct user. The USER_UUID cookie does not contain the same uuid as provided by Liferay (as of now I didn't check if it's a hash of the uuid).
Long story short, I'm looking for a way to recognize the currently logged in user and be able to pass the credentials and additional information to my application.
I will take care of security concerns like manipulated cookies etc. subsequently. Maybe that will raise another question wenn I get to that point ;-)
I'd really appriciate any help or push in the right direction.
Thanks in advance guys ... sebastian
Some possibilities:
Make your application a portlet application
Publish your Liferay Database through LDAP (EE only) and use a separate SSO application
Create a Liferay-Hook that sets a cookie (to "/") containing the required user information - encryption and signatures are on yourself. You can create hooks that get executed on every successful login
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
Has anyone successfully implemented the Google Identity Toolkit, an implementation of an Account Chooser. I followed the initial steps here, but I still have a few questions, as I don't quite know how to handle the entire data flow. I'm using Clojure / Compojure in the back-end:
http://havethunk.wordpress.com/2011/08/10/google-identity-toolkit-asp-net-mvc3/
http://code.google.com/apis/identitytoolkit/v1/acguide.html
A) don't quite understand how ID Provider authentication, fits into my data model
when implementing the callbackURL, what data should I expect, and
how's that session state managed by GITkit (and all Account Choosers)
B) Is there a way to set this up the 'callbackURL' for development.
the identity provider would need a URL that it can redirect back to
C) How can the GITkit / Account Chooser workflow let my users register an account that's native to my app?
Thanks in advance
The questions aren't entirely clear, but I've done an implementation of GITkit in ruby and can give you some pointers.
A) The callback URL is what handles the assertion from the identity providers. Rightnow GITKit only does OpenID, so the URL will contain an OpenID response either in the query parameters or as the POST body. You'll need to do a few things:
1) Call verifyAssertion in the gitkit API and pass the params/post body. This will return a JSON response that contains the user details (assuming assertion is valid). There are some other checks you should do as well
2) Decide what to do with the assertion. If it is an existing user, most likely you'll just establish a session and save the user ID. If it's a new user, you can either create a new account and start a session immediately, or defer that and redirect them to a signup page.
3) Render HTML/JS to notify the widget. There are different status codes and data you can return that changes the flow.
GITKit itself doesn't really manage session state, that's up to your app. Some of the reference implementations have code to help, but it's not part of the API. The widget does have some state that you can control with JS (add account, show as logged in, etc) and uses local storage in the browser.
The docs give some details and example code for how this should be implemented.
B) Of course. The URL is just configured in the javascript widget when you call setConfig() It can be set to localhost or any staging server for development. So long as your browser can reach it you're OK.
C) By "native", I assume you mean where they're signing up with just a username/password instead of using an IDP. If so, the user just has to enter their email address when logging in. If that email address matches a known IDP it'll attempt to authenticate with OpenID, otherwise if it's a new user it'll redirect to whatever signup page you configured in the widget. That signup page would just ask the user to create a password like you normally would. You should also return whether or not accounts are 'legacy' (password) accounts in the userStatus checks.
Hope that helps.
For anyone's future reference. I was able to resolve the issue. You can follow this thread of how's it's done in Clojure.
I got it working with Ring/Compojure, and another fellow showed me his solution in Webnoir.
HTH
Everything I have tried requires the end user to sign in to yahoo...this won't work because the end user doesn't know the password or the username. This should be automated otherwise flickr wont work
You probably won't get this to work the way you want. OAuth requires the end user to authenticate with the service (Flickr) and physically authorize your application. So at the very least, you're going to have to interact with their server as a user if you want to authorize your application for use.
As a side note, you may want to investigate whether or not you can POST the required variables to Yahoo via some sort of script. Use Firefox and the Live HTTP Headers extension to view the POST information. This may or may not work, as my previous experience with some Yahoo forms require cookies designed to foil robotic submissions.