I am using J2EE authentication for my application, and mine is single-page web application, which uses '#bookmark' to refresh different sections using Ajax. I wanted to make these links bookmarkable. But the '#bookmark' part is getting removed after authentication.
For example I've a page, which is authenticated, with URL 'http://mydomain/my-page' and if '#my-section' is added to it, page will refresh the section using Ajax, and URL looks like 'http://mydomain/my-page#my-section'. If I book mark this link, and use it before logging-in, J2EE authentication redirects me to login page, after I provide my credentials, it redirects me to 'http://mydomain/my-page'.
How can I make it to redirect to the URL with '#my-section' part intact?
I can think of a solution using Valve implementation, but is there any other way of doing it?
Using J2EE Form based authentication on Tomcat7, and UserDatabaseRealm as security realm.
After some reading, I understood that URL hash is never sent to server, and it is not possible automatically.
we might've to implement solution to store the URL hash locally, and use it to add the same to the URL after successful login redirection.
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 been developing a web app consisting of a login page and users database maintenance and i am using tomcat authentication to verify users credentials. I have configured the tomcat in such a way that when the url of certain servlet is called the authentication pops up. But i can use that authentication only once and after logging in if i come back to the same page there is no authentication from the server.
Yeah i found the answer. Just include the Session.Invalidate() code in your corresponding sign out page and it terminates the session. But you have to change the authentication from to FORM.
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.
I'm going to rewrite my previous question.
Glassfish redirects after form login to the last accessed resource, how do I go about to turn this off?
Our problem is that we get 415 in FF and IE because if I have a JSESSION cookie Glassfish will redirect to the last resource I tried to access but does not switch content type from (x-form-urlencoded).
Pseudo example (requests are the browsers' XMLHttpRequest):
GET /secure/resouce1 (json) -> Response "you're not logged in."
GET /login.xhtml
POST /j_secure (x-form-urlencoded) -> New location /secure/resource1 (x-form-urlencoded)
GET /secure/resource1 (x-form-urlencoded) <- HTTP ERROR 415 content type not JSON.
You will probably need to write a Filter to check for and catch that case. I like this tutorial (hoping the translation to English is understandable).
In my opinion it is better to use Basic or Digest authentication over SSL for RESTful services. Other options are including the credentials as part of the payload or creating a dedicated login service, which accepts credentials and returns a token. There are various reasons why form based authentication is less suitable for RESTful service: it requires a session, it does not use the existing HTTP Authorization and more.
If you need to call your RESTful service using AJAX then using a cookie for authentication can be a valid solution. They should only affect if the user can make a call, but not how the server responds.
If you would like to keep using form based authentication for your application I would suggest adding an additional JAAS authentication provider which will handle the RESTful services authentication. You can read more about it here.
Another option, which should be easier than JAAS, would be using Spring Security or Apache Shiro instead of the container based authentication.
Here is an example of configuring form based authentication with Spring Security. This post shows an example of how to secure RESTful services using Spring Security.
in your login page
reset the JSESSIONID cookie to prevent redirect last page
// login_form.jsp
Cookie jsess = new Cookie("JSESSIONID", null);
jsess.setMaxAge(0);
jsess.setPath(pageContext.getServletContext().getContextPath());
response.addCookie(jsess);
I have a java web application running on tomcat, and will use single sign on (against an Active Directory) for authentication.
What I want to accomplish is, that only certain pages in the web app are allowed to be the first "landing page" in the site.
The use case is that one may point the browser to index.jsp, and then be authenticated behind the scenes, and then be forwarded to some_content.jsp.
However, if I point the browser directly to some_content.jsp, I want the request to be denied, somehow, and NOT authenticated behind the scenes.
To rephrase, if I go to some_content.jsp first, without already being authenticated, I do not want authentication to happen, eventhough I have SSO set up.
Is it a matter of some fairly simple security-constraint, or what could a solution be? I am looking for a solution that can be configured, rather than adding code.
Thanks a lot!
This won't work with container managed security. The only method to have a concrete login-entry-point with container-manager auth like in Tomcat is FORM auth. I use SPNEGO auth myself and Tomcat will perform it on any URL if it is denoted as protected. So a routing login page is not possible unless you write a custom authenticator.