My web application consists of 2 parts:
GWT app that does all the work.
Handmade servlet aimed to handle OpenID authentication facility.
I need to wire p.2 to p.1. I'm reading LoginSecurityFAQ, so I'd like to confirm whether my understanding is correct here.
Once OpenID provider confirms that user is OK and gives me its identity, I should register the session.
To "register" the session, I should store somewhere in my DB a mapping between OpenID identity and a session id (identity="https://www.google.com/accounts/o8/id?id=wwyruiwncuyrwieruyfakefakefake" and session id is a large random string like "HiuhoiuhIUHOIUY87Y*&Ttgi6yUYGIuygUHGugyg^G6g").
That session id should be stored on client side in a cookie.
Every time any request is sent from client side, on server side I should check whether client's session id is still fresh enough (alive) and I should also use it to resolve client's identity in case I need it.
Is it right? Is it secure enough in case session ID is really large?
Your thinking is right, I do it more or less like that too.
Just a few notes:
1) In case you want to persist the identity, do not forget to set the realm right. Depending on OpenID provider you may end up with a different identity for the same user on next login otherwise. I think Google's OpenID requires you to use your server name plus port:
openIdManager.setRealm("http://" + req.getServerName() + ":" + req.getServerPort());
2) Why create your own session management? It is quite a lot of extra work and you might end up writing up something insecure. Use common http servlet sessions.
3) You won't need to manage session timeouts if you use http sessions, but if you need to intercept all GWT RPC calls, the right place might be overriding service method in your RemoteServiceServlet implementation.
Related
Hi I am looking for a way to authenticate users when they make WebSocket connection and simply if they are not authenticated close the connection. I am using Dropwizard framework and Atmosphere for the WebSocket connections. Here is the example that I use.
It would be great if I could use '#Auth' annotation provided by Dropwizard for authentication when the connection is establishing.
How are you exposing this? Is it through a javascript frontend?
You are using the servlet based approach as described in your link and here: https://cvwjensen.wordpress.com/2014/08/02/websockets-in-dropwizard/, and not the jersey atmosphere extension?
If you are using the servlet based approach would recommend using a token-based approach putting the token in the http header an then access this header in the #Ready handler method, like this:
#Ready
public String onReady(final AtmosphereResource resource) {
String AuthHeader = resource.getRequest().getHeader("Authorization");
...DO AUTH HERE
logger.info("Resource {} connected ", resource.uuid());
return "Connect " + resource.uuid();
}
Then, you could also easily close the connection if auth fails. However, depending on your client side implementation, you might want to think about this. If the client auto-reconnects on close, you have a scenario of constant closing and opening of sockets that may cause a resource drain. You could, if auth is not successful, store a private variable that states whether or not this instance is authenticated and just drop sending any messages to or process any messages from it. That would also be a "obscure" way of letting an attacker know that auth failed, it simply is in a limbo state; connected, but not failed or closed. Just not receiving any data. But again, this is specific to your implementation.
Jwt auth is an option, check this out: https://github.com/ToastShaman/dropwizard-auth-jwt. I have, although not made it public, ported this implementation to dropwizard 0.8rc3-SNAPSHOT. If you need this, please let me know and I can post it to github.
Here is what I'm trying to do: I have an authentication EJB that can grant user a "ticket" (pair of key and token) by validating username and password. Clients should pass the ticket every call to remote EJB and such ticket should be able to be fetched by EJB (method, or interceptor) and EJB/ or interceptor should validate the ticket and determine whether the call is valid or not.
I don't want to add ticket as parameter to each function that requires authentication, and I believe there should be a way to implement this. I've looked through several articles about JAAS custom login module, but still can't find a non-vendor specific way to do this. (And I am trying to avoid vendor specific implementation)
If JAAS can't do the job, is there anything like "header" in EJB?
Couldn't you just use roles to perform this authorization? Instead of granting a ticket to a user, assign him a role.
Then, it's just a matter of using the inbuilt functionality of checking whether a user is in a role or not.
Although I agree with #EdH, i.e. use #RunAs, you can accomplish what you want by adding to the EJB context your token.
Red Hat does something similar here by using the interface EJBClientInterceptor.
By looking the code of ReceiverInterceptor (which implements the EJBClientInterceptor) you can see how to modify the EJB context (on the client-side) and add your token:
context.setReceiverInvocationContext(new
EJBReceiverInvocationContext(context, receiverContext));
context.sendRequest();
Is there a way to run separate instances for each connection -or let's say user-, like rmi, via JAX-WS?
HTTP is stateless, therefore each request is on its own. The instance of the service is just one, and that's good.
If you want to store session information (i.e. separate data for each client) you have a couple of options that let you identify each subsequent request as belonging to the same user:
create your own solution - let the client pass a token that identifies his session, and load that session from an in-memory or db-persisted Map<String, ...>.
use OAuth
Situation: I have a "dumb" Javascript frontend that can contact some kind of SSO middleware (MW). The MW can obtain sessions by issuing requests that contain authentication credentials (username, password). I.e. the session will be created for a certain user.
My frontend needs to "restart" the session to gain the user's permissions to the target system. For that i need a valid session cookie.
The target system is not under my control (could be a more or less public WFS, WMS, etc.), so i cannot add any SSO mechanism to it.
Question: Is it possible to "steal" a Session forging a request which URL contains a valid session ID in the jsessionid parameter?
Goal : Issue such a request to a Servlet and make it respond with a Set-Cookie header that contains the same id. That way the frontend joins the session and may do whatever the user, which was used to create the session, is able to do.
Your best bet is a shared datasource (RDBMS?) where the shared information is stored with some long, auto-generated, unique identifier as key (java.util.UUID maybe?) and then pass this key around.
I have a need to create a HttpSession (via cookie) whenever a client invokes a particular UI.
Assumptions:
Let's assuming that I'm not going to worry about any deep oAuth-like authentication dance. JESSIONSID cookie impersonation is not an issue for now.
The server is tomcat, thus a JSESSIONID cookie is sent down to the client if a new session is created.
Design issues:
I'm grappling with how to design the URI. What is actually the REST resource ? I already have /users and /users/{someuserid}. I wanted to use /auth/login but in one previous SO question, one cited article says that we should not have verbs in the url. I've noticed that even Google makes the same mistake by having https://www.google.com/accounts/OAuthGetRequestToken. So in your opinion, are /auth/login/johndoe (login) and /auth/logout/johndoe (logout) good options ?
UPDATE:
I've changed my design. I'm now thinking of using the URIs /session/johndoe (PUT for login, DELETE for logout). It should still be within the limits of the REST ethos ?
Aren't sessions irrelevant in REST Style Architecture?
http://www.prescod.net/rest/mistakes/
I am in the midst of creating a REST endpoint that recognizes sessions. I've standardized on:
POST /sessions => returns Location: http://server/api/sessions/1qazwsxcvdf
DELETE /sessions/1qazwsxcvdf => invalidates session
It is working well.