I have a web application which requires username and password authentication to enter.
What I am doing is, authenticate a user from a stand alone Java app, which would do so by making Http request to the server using username and password. Then I would retrieve JSESSIONID cookie from response of server.
Now what I want is to use this JSESSIONID to continue session on browser i.e. to let user navigate pages of my web app which would be opened by my stand alone java app which I use for authentication.
Is this possible? Or is there any other way to do so.
Cookie can be changed using below mentioned methods.
Cookie cookie = new Cookie("JSESSIONID", NEWSESSIONID);
response.addCookie(cookie);
From your application you can send JSESSIONID as parameter while opening browser first time and reset your cookie using above method either in filter or servlet. This will reset your cookie in client side once you send response back. Next request on wards you will be able to access the session created previously.
It's possible but it's not that simple.
Since web applications don't share sessions, what you're looking for is a Single Sign On (SSO) solution, which involves an "Identity Provider" (IdM) that authenticates users for one or more "Service Providers" (SP). In this case, your servlet is the IdM and your web app is an SP.
Depending on your deployment, the following are third-party, open-source SSO libraries that you may be able to use:
Kerberos
PicketLink (for JBOSS)
OpenAM (for Tomcat)
If you don't want to use a third-party library, you may also be able to modify your servlet to be the IdM. Either way, I suggest reading a little about Security Assertion Markup Language (SAML) before deciding on a solution. SAML is a popular method that the above libraries implement.
Related
I have multiple web applications running in different domains. Okta is the identity/auth provider for all these applications. After integrating with Okta in one of the application (following the Java example provided in Okta documentation), a new cookie (sid) is being created in Okta domain (https://developer.okta.com/docs/reference/api/sessions/).
How do I use this to SSO into other web application. What is the best approach to allow access to other application without prompting login credentials again?
Do I need to invoke getCurrentSession API in every application and redirect to login page only if the API response is 404 (as per doc, getCurrentSession will retrieve the current active session based on the Okta cookie).
Please share thoughts.
It all depends on how you integrate your apps: redirect to Okta or using Okta widget. If you do redirect it's pretty much guaranteed to have zero issues authenticating in your second app, as your redirect for second app will send sid cookie back to Okta, which was set while authenticating with your first app.
With widget things may become bit complicated, as it depends on 3rd party cookies. okta-auth-js GitHub repo has some examples on how you can check if session exists with okta, when you trying to authenticate a user. Check https://github.com/okta/okta-auth-js#third-party-cookies
I have created Java Web Application by using Netbeans IDE. I have created entities with relationships. Webpages are simple dashboards where I can add new entities, change them and delete them.
I have added Restful web services to my entities. So web page will be available only for admin and I want to create client application that will have access only for his own data. That means client must login or register to my server.
When user logins/registers on website, server will create session for this user. I know that in RESTful service there is no sessions. My thought is to pass login and password every time when client wants to do some operation with server.
Question: is there any other method to create something like session between client and server? I hope it is not connected with encryption.
There are many options for authentication as well as authorization. If you want to use simple authentication then 'Basic Auth' of HTTP. Check out https://www.rfc-editor.org/rfc/rfc2617 for details. Remember that this is unsafe because the username/password flows on wire. Anyone can sniff username/password. This is updated by new RFC7235 - https://www.rfc-editor.org/rfc/rfc7235#section-4
Safer choice is oAuth. Explained in RFC6749 https://www.rfc-editor.org/rfc/rfc6749. In this case an access token goes with each request.
In both the cases the credential details travel with headers. No interference with parameters.
I have 4 single page applications with same technologies: Spring MVC, Spring Security, Angulajs.
Each application has own ldap authentication and authorization. We want to build a single sign architecture and make a central authentication application. And make the other 4 application use this central application.
When user login into one of the apps, he should not need to login the others.
What is the easy way to implent this in server side and client side?
What you want is Single Sign-On (SSO). There are two options:
Use some existed SSO server like CAS.
Do it yourself using subdomain cookie technique.
First option is exactly what you want implement. When you open URL of app1 you will be redirected to SSO server and prompted for login/password. After successful authentication you will be redirected to app1 URL. Now if you open app2 URL you will be signed in automatically. One of advantages is that user password is stored only in SSO server.
Second option is more lightweight IMHO, because instead of using existed SSO server for sharing authentication information between your apps you use HTTP cookies. From the other side you need to write some minimal authentication code which may be less secure.
Subdomain cookie technique:
Use subdomains for all your apps (app1.domain.com, app2.domain.com)
When user connects to app1, generate some token (your session id), store it in some shared DB and as a cookie for domain.com
When user opens app2, check if token is present (as a cookie for domain.com), verify that it is valid (use shared DB) and allow access.
It is very simple algorithm that do not take into account all possible security vulnerabilities (like session fixation for example). So if you do not have enough time to solve them it may be better to go with first option.
What is the best way to do authentication and authorization in web services?
I am developing a set of web services, requiring role based access control.
Using metro - SOAP, simple java without EJBs.
I want to Authenticate the user just one time, using username and
password, to be matched against a data base. In the subsequent calls.
I would like to use some kind of session management. Could be some
session id, retrieved to the client at login, to be presented in all
calls.
So Far:
Read authentication using a database - but I want application level validation;
Read application authentication with jax-ws - but i don't want to do the authentication mechanism every time;
I think I can use a SOAP Handler, to intercept all the messages, and do the authorization control in the hander, using some session identifier token, that comes with the message, that can be matched against an identifier saved in the data base, in the login web method.
EDIT:
I still have some questions:
How to know the name of the web method being called?
What kind of token should I use?
How to pass this token between calls?
EDIT 2
Because of #ag112 answer:
I'm using Glassfish.
I use WS-Policy and WS-Security to encrypt and sign the messages. Using Mutual Certificate Authentication. I would like to complement this message level security between applications, with the authentication and authorization for the users also in message level.
I am just developing the services, and I don't know almost nothing the clients, just that they could be created in different languages.
At this point I think the most important thing is to do what ever I need to do to authenticate and authentication the users, I the most easy way to be implemented for the client applications.
#Luis: Here are my inputs.
Well exact solution for your problem depends upon kind of web service clients you expect, do you have control over web service client system, your app server etc.....but assuming you don't have any control over web service client, for you it is just a SOAP message over HTTP transport, here is probable solution.
You can of course performs session management & authentication at message level or transport level. It means either you can have session token and auth token information in SOAP message or you can use standard HTTP Session and HTTP authentication mechanism.
Of course transport level solution is much simpler and industry wide standard in case if transport layer is HTTP. For message level, ws specifications like ws-security can be used.
Your each web service request is simple HTTP GET/POST identified by a unique HTTP URI.
Typically in jax-ws metro environment, WSServlet is one which entry servlet for any web service call and which eventually delegates the call to right service provider implementation class. Since you application is going to be deployed in web server, you can exploit all session and authentication facilities provided by J2ee web container.
Since you are looking for role-based access control, I would use standard <web-resource-collection> in web.xml to specify which role you would like to have in case of particular HTTP URI. You can use standard JAAS login module which can do authentication and populates the JAAS subject with role. If user name/password are provided in SOAP XML, JAAS login module can also search/parse SOAP XML to retrieve those information. JAAS/app server will automatically create auth token and store it as cookie so that each subsequent request need not to go through authentication process again. This is all J2ee standard. You can find plenty of help on internet on this. Please let me know your app server so that I can provide you additional details.
If you still want to use SOAP message level session management, authentication & authorization process, then to provide you more details, may I know more details about your client side.
EDIT1:
Well based on your further inputs, here is my more thoughts:
Message security namely encryption and signature needs to happen each message travels between server and client. where as message authentication- you intend to do once and give a session token/auth token to client for subsequent calls.
Question still remains: if you put a unique session Identifier in SOAP response of first time authentication, do you expect client to parse SOAP response XML and ensure that client should send you session identifier each time in subsequent SOAP requests.
OR
You want to keep session management transparent to client and for client it needs to send username/password token first time and subsequent calls need not require any username/password token. In this case you would need to rely on transport based session management for e.g. HTTP cookies
Now what is the best for you depends upon your use case. Can you tell me what is expected use case flow? how another system (web service client) makes more than one service call to your system? Is another system user driven/some background process? What is exact need that you want only first service call to go through authentication process not subsequent calls?
PS: Glassfish server provides a way of configuring message authentication provider which automatically enables/disables message level authentication.
EDIT2:
I understand you do not want to store user credentials in client app and web service server need those user credentials.
OAuth is open standard protocol which allows site A to access user's private data on site B. Ultimate idea is site A gets auth token which has specific expiry time. So Token containing encrypted from of user credentials or jsession id help you avoid need of re-authentication. You only need to decide where you want to keep token at client app side
You can keep token as cookie if transport is HTTP protocol.
Having said that ofcourse passing user credentials each time seems bit easier and straight forward.
You can also go for OpenEJB.
It used JAAS with WS-Security.
I hope the link is useful.
After all the help, I create this answer to simplify, and summarize all the ideas that was discussed.
The questions has 2 requisites:
Message level security;
One time authentication.
With ag112 help, this is hard to do, or to elegant in any way. So here are to conclusions:
For message level security send the user
credentials every time (place it in SOAP header);
For one time authentication use transport level security, and do a
session management.
I prefer the first one, because the message level was the biggest requisite.
As had no answers, following #unhillbilly advise, I answer my own question, with the progress so far:
How to know the name of the web method
being called;
Using a SOAP handler, finding the name of the first element in the body.
What kind of token should I use;
I decide to use a 128 bits token, representing each session. The Webservices, continue to be session-less, the key is just for authorizations purposes.
How to pass this token between calls.
For the login web method the result has the token, in each subsequent calls, the token is a parameter.
is there a better answer?
I'm using gwt on my glassfish server, and I'm attempting to make some of my RPC calls authenticated via cookies. Is this possible? Are there any examples out there of how to code it?
Depending only on the cookie for authentication will make your website/services vulnerable to Cross-Site Request Forging/XSRF/CSRF attacks - read more on that in Security for GWT Applications.
The best way would be to double check the value you get from the cookie and with the one that's been transported to the server by some other means - as part of the request (header, a custom field, etc).
Other than that, there are many tutorials covering the subject - just search for Java (servlet) authentication - it doesn't have to be GWT-specific. The Google Web Toolkit Group also has many threads about the subject.
I assume that you use GWT's RPC servlet for handling requests made by the client.
One option that comes to my mind is to write and configure a ServletFilter which can examine the cookie, before the request reaches GWT's servlet.
You might rethink using cookies as it is a potencial security hole.
Why not put your communication to HTTPS?
Can you not just use the standard 'session' scope, i.e.
request.getSession()
A pattern I use in GWT apps is to have a separate 'old fashioned' login form which sets up the session. The GWT app's host page is then displayed after they have successfully logged in.
If the necessary values aren't in the session, then the user isn't logged in. Your service should return an exception, maybe, which instructs the GWT app to redirect to the login page, or display an error.