I have a Java+Spring application.
Assuming the browser settings are all correct and site is allowed, is it possible to retrieve logged in AD user credentials from an http request? Which fields are they? AUTH_USER? Are they coming with every request (GET, POST, PUT, DELETE etc).
I've successfully integrated AD authentication, with the user manually typing in their AD user and password. Now i am wondering, can login be done more automatically, retrieving credential from a browser's request?
I don't think this is possible. If you want an elegant solution instead of checking each user/password in your filter for example, have an eye to JWT. You could encapsulate your AD user in it and send the token to the client, itself sending back to you in a header.
The counterpart is that you have to integrate all the jwt part, as long as JWT is not native in Spring. I'm currently working on a personal project to integrate jwt and that's not so easy for someone starting with Spring Security.
This link seems ok for Spring
Related
I have a web application that provides several rest services (Jersey). Most of the endpoints are secured by BASIC authentification. Further more I use SSL for transport and demand POSTs for every call.
The clients/consumers are android apps.
So far so good. The only service that seems to be vulnerable is the registration. It's the 'first' service to call and a user does not exist yet. So I cannot use OAuth, etc. I also have to keep the endpoint easy accessible to enable the user to regster.
How do I secure this service, so it's not spammed by a bot flooding my database?
How about these?
Use a registration link with a token in the request parameter. Ensure that the tokens expire after sometime. You could create a token endpoint url as well for a client to get a valid token.
Use a custom header or a dynamic custom header in your request. Additionally, you could check for a dynamic custom header to validate the request's authenticity.
Use registration confirmation workflows, such as an email / text verification as soon the registration is done. Run a process every day to delete any user accounts, which are not validated in say x days.
I do not think you can really secure the registration URL in a HTTP way. IMHO, anyone who has the registration url can be a right guy trying to register. So if you ask me, option 3 is better than others.
I am planing to write an API for a mobile app. To lower the barrier for first time users i do not want a login screen on the first start. So what I want is, if the app notices it is it's first start it should register itself:
/register
A standard User should be generated like Name: GuestXX43, Authtoken XX43-58asda5-54asd, some additional Data
The user is now able to make other endpoint request due to its auth token.
But how do I check for the correct auth token on every Request?
/user [Update]
the user is also able to update his username and password to reloggin on another Device.
Which auth method will suite these thoughts, is there any doubt using this kind of auth flow?
Thanks guys
Are you using Google Cloud Endpoints? If the user credentials is set in some header, you can retrieve it in the backend via injecting HttpServletRequest in Java or check HTTP_YOUR_HEADER_NAME environment variables in Python.
Also you can try custom authenticator if you uses Java; this post can be relevant: Google Cloud Endpoints and user's authentication.
I am making an Android app which will fetch data from my API.
First thing my app will do is to let users signin using their credentials.
My question is does my API need to handle sessions? or should I authenticate the user for every request?
Will the native android app hold the user credentials on the device and send them along for every request after signing in?
I am using Retrofit. How would I send user credentials after they have signed in?
This will be a good time to take a deep dive and read into OAuth. Your use case seems to match perfectly. There are 2 main steps you will need: Authentication and Authorization. I have briefly explained them here: Authentication of a resource in Dropwizard. You can ignore the DropWizard part, the REST concept remains the same. The short version of the description could be like this: A user installs your app on the phone. They authenticate ONCE using their username and password (POST request to your REST over SSL). Your service authenticates the user and return back with a "refresh_token" and an "access_token" which the app saves on its side while you map and save the access_token/refresh_token on service side with the user. With every subsequent request your app is going ot send the "access_token" as a part of "Authentication" header which you, on the serverside, will parse and check if the access_token is still alive (assuming that access_token expires) and if it is alive, then complete the authorization/authentication process. If by any chance, the access token has expired, 401 will be returned back to your app. The app will have to then use "refresh_token" to get a new access_token and once approved with a new access_token (which again ofcourse is mapped on server side to the user's identity) all the subsequent calls will use the new access_token, till the time it expires. This is a simplistic version of OAuth and does not follow the specs to the letter. It's a very basic authentication/authorization flow to get you started. I hope this helps!
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'm writing a standalone application with accesses the Adwords API. The oauth2 authentication and authorization works fine.
My problem is that I want to save the refreshtoken in a textfile and use it directly the next time I run the app to restore my credentials. The refreshtoken should be valid for 14 days, so restoring the access credentials would very good.
I haven't found an example which works. Can someone help?
The refresh token is not much different from the authorization tokens.
OAuth2.0 has several flows that can be used to get access to the servers. The common (and savest) flow is the so called Authorization Code Flow (detailed info here).
There your application asks the authorization server for an authorization code the first time the user wants to use your application. The user will get that authorization code over the website when he logs in and grants your application access to the service. Your application sends this code to the authorization server in order to get the first access token(and with it the refresh token). It is the same server you need to send the refresh token to.
Now, I don't know exactly what the server's uri is in your case, but this would be an example of a POST request you can send the server:
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
client_id=YOUR_CLIENT_ID_HERE&
client_secret=YOUR_CLIENT_SECRET_HERE&
refresh_token=THE_REFRESH_TOKEN_HERE&
grant_type=refresh_token
If the request is valid, the server will respond with a new Access Token. Here you can find more informations about the specific requests you can make.
Keep in mind that every token (access- and refresh tokens) have to be stored savely. The best way to do this is to save it encrypted and when sending the tokens use only POST requests and https. But this wasn't your question.
I hope I could help you with this.