In my Spring Boot web app I want to integrate Spring Security for authentication. There are the following conditions:
Only username must be given
The username is set in a GET param (e. g. "username") and comes with the first request for a ressource
No password is used
Authentication will be done by searching for the username in a separate system (not defined right now)
Could someone outline what an appropriate solution with Spring Security might look like?
Well if you do want to go this way you could go for basic auth with a custom filter as described here: https://www.baeldung.com/spring-security-basic-authentication
The username would be passed on every request, not on a first request. What you seem to be suggesting with "first request" is some form of token based system that would be sent for all requests following the "authenticating" request.
Related
I'm learning Ouath2 implementation in spring boot below way.
I want user to authorize himself first and then get a token, once get a token I want user to send that token with its REST API request to get resources.
Then resource server will verify the token and once valid will release the resource back to user request.
I know there are many examples and studies are available, but what I have observed that, most of the example are using GOOGLE, FACEBOOK etc to authenticate their user, that's not gonna help to understand my learning to develop everything manually for better understanding.
My ask is, Is anyone can share any example or references where I have control over (user authentication process + release token) and once user has token, then on resource server (validate the token with authorization server + full fill user request) I could implement token validation and return result ?
I'm want to do this authentication mechanism by myself for b. Is there any open source example is available just for learning purpose ?
All suggestions are welcome
The name of the thing your are looking for is Keycloak or Okta (these two are most popular). There are a lot of tutorials of course.
I would like to authenticate with
http://myhost/login?user=...&password=...
and logout with
http://myhost/logout
I am using Gradle, Spring Boot and Java config, so no web.xml, no context configurations, no web forms and so on.
Can't escape from google noise on multipage and multifile samples...
Have you considered using a servlet filter? Seems like what you want to do for passing the username and password as http parameters. Otherwise, you might also consider HTTP BASIC authentication. It passes the username and password in the http headers using base64 "encryption". Of course, complete website security is a different discussion.
See this example of using HTTP BASIC authentication.
One approach is using tokens.
The login service would accept the credentials, generate a token (a UUID type 4 for example, see https://en.wikipedia.org/wiki/Universally_unique_identifier), store the token in a table and return it.
In every call, the client would have to send the token in the header or as another parameter, so a filter or something would check it to allow access.
On logout, the token would be deleted (you may want to have a process that deletes the tokens after a certain amount of time or something like that).
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've been learning spring-ws for little over a week and I've set up a simple web service.
I'm testing it using soapui and specifying a username and password in the request properties.
My web service has no security layer nor do I want to add one. I just need to pull the username and password out of the request to make requests to another service. I don't want to have to specify a username or password in my request body itself.
All I want to do is retrieve the username and password from the request from soapui. Does anyone know where the username and password are in the request? Are they in a http header or the soap header. The soap header appears to be empty in soapui.
I have tried writing my own interceptor to my endpoint and getting the soap header but it appears to be empty.
I have also tried retrieving them using SecurityContextHolder.getContext().getAuthentication();
but this returns null.
I also tried to interrogate the HttpServletRequest from my endpoint to see if the user details were in there, sadly not.
Does anyone have any ideas or good knowledge of this area?
Since there is not authentication in your application, your server does not prompt for authentication and the parameters you specify in soapUI are never used (not included in the http request). Furthermore there is not point using
SecurityContextHolder.getContext().getAuthentication()
since you don't have authentication, there is no authenticated user and it returns null as you said.
If you need username/password to access another resource, you should specify them as configuration parameters in your web service.
I'm hosting a REST web service in a Grails application, using Spring Security, i.e.:
#Secured(['IS_AUTHENTICATED_REMEMBERED'])
def save = {
println "Save Ride REST WebMethod called"
}
I'm calling it from an Android app. (Calling the unsecured service works just fine.)
To call the service, I'm manually building up a request (HttpUriRequest) and executing it with an HttpClient.
I'm wondering what the best practices are, and how to implement them... Specifically, should I:
Perform a login once, to retrieve a JSESSION_ID, then add a header containing it into the HttpUriRequest for each subsequent request?
Or (not sure how I would even do this) include the login and password directly on each request, foregoing the cookie/server-side session
I think I can get option 1 working, but am not sure if Spring Security permits (2), if that's the way to go... Thanks!
--also, there isn't any library I'm missing that would do all this for me is there? :)
Spring security does support both basic authentication and form based authentication (embedding the username/password in the URL).
A REST service is generally authenticated on each and every request, not normally by a session. The default spring security authentication (assuming you're on 3.x) should look for basic authentication parameters or form parameters (j_username and j_password) (in the form http://you.com/rest_service?j_username=xyz&j_password=abc).
Manually tacking the j_username/j_password onto the URL, adding them as post parameters (I believe), or setting the basic authentication username/password should all work to authenticate a REST service against the default Spring Security interceptors, right out of the box.
I will admit that I haven't tried this on REST services, though I do clearly recall reading exactly this in the docs as I did the same for basic page logins on spring security recently. Disclaimer over.
I think you can use a login-once-and-get-a-token method that's similar to how oauth works.
sending username and password across the network outside of secured channel(https/ssl) is a terrible idea. anyone on the network can sniff your request package and see the clear text password.
on the other hand, if you use a token method, since the token string is randomly generated, even the token is compromised, the worst case is someone can use the token accessing your REST API.
another solution is going through ssl tunnel(HTTPS). i have actually done a comparison and result shows: 80 requests/min(https) vs 300 requests/min(http)