I am unable to find a REST webservice way to Authenticate (Login) and know his roles (authorization). Although, Openbravo wiki says there is a way to login, but doesnt provide any other detail about its URL etc. Can anyone help in this regard? Thanks
EDIT
I have also posted this question on Openbravo forum. Hope this will benefits others.
The REST Webservice provides two methods for logging in:
login with login/password passed as request parameters (the parameters names are resp.
l and p)
basic http authentication
If you use the first option and make a get request, the parameters are added to the url like:
http://server/openbravo/ws/dal/Country?l=user&p=password
If you make a post request the parameters are sent as the body of the request. Here is how to in java.
To use the basic http authentication you have to set the Authorization header and set the credentials as a string "user:password". Here is how.
Basically openbravo comes with two different kind of authentication by default.
DefaultAuthenticationManager
AutoLogonAuthenticationManager
Both classes extends AuthenticationManager which is an abstract class. So that means Openbravo provides expandability here for custom Authentication manager.
As for as web service authentication , there is a method called webServiceAuthenticate inside AuthenticationManager which does the authentication for the REST Web services.
You can check the documentation here
Related
I have been asked to test my Rest API in JMeter and configured my service details in HTTP Request tab in JMeter and unfortunately i am seeing Authentication failed error even though it displays correct information in Request tab.
Here is my Header Manager section as below...
This is my request and using POST method for this.
Can you pls help in getting this fixed...
you have to implement correct correlation.
Authentication must be executed every time.
The authorization token is a random value that you get from previous authentication.
You have to extract it (maybe with a regular expression) and use it in the HTTP operation.
The recommended way of testing resources protected by Basic HTTP Authentication is using HTTP Authorization Manager.
Add HTTP Authorization Manager to your test plan
Provide Base URL and credentials (plain text)
That's it, you don't need to add Authorization header manually, JMeter will automatically generate it, check out How to Use HTTP Basic Authentication in JMeter article for more details if required.
I have deployed webservice in Tomcat using Apache CXF. How would I proceed in securing that web service using OAuth 2.0?
I have gone through the below URL but without finding any suitable solution. A working example or tutorials on how to implement oAuth 2.0 for simple web service?
Original tutorial link:
JAX-RS: OAuth2
I was confronted with the same issue recently. After a decent amount of research, I have found (and this could be limited to me alone) that this is quite complicated.
It is possible to attach the required "authorization header" to a SOAP webservice call in this manner :
Map<String, Object> req_ctx = ((BindingProvider)port).getRequestContext();
req_ctx.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, WS_URL);
Map<String, List<String>> headers = new HashMap<String, List<String>>();
headers.put("key", Collections.singletonList("yourkey"));
//... all other parameters required.
req_ctx.put(MessageContext.HTTP_REQUEST_HEADERS, headers);
The request can then be checked on the server side as such :
MessageContext mctx = wsctx.getMessageContext();
//get detail from request headers
Map http_headers = (Map) mctx.get(MessageContext.HTTP_REQUEST_HEADERS);
List userList = (List) http_headers.get("key");
//... get other information required here
And thus you can validate the request.
On a side note
It is to note, from my findings, oAuth2 is not very useful for simply securing your API - simply protecting it from outside use.
The reasoning
With oAuth 1, you could use the authentication to validate a user by their key. You knew they were authorized because they have successfully signed the request, and thus you would allow them access to the information.
With oAuth 2, the protocol requires you to use HTTPS. Then why not just use application authentication with your API? I have found oAuth 2 to be very useful to access 3rd party applications with the original set of credentials (the goal of the protocol). But unless you need to do this, there is no need (again IMO) to implement the full oAuth. If you ONLY looking to secure your API, just do it using SSL and a key or username/password combination.
See also:
Application Authentication With JAX-WS
CFX User Guide
How is OAuth 2 different from OAuth 1?
Designing a Secure REST API without oAuth - more useful for general understanding.
I've added a short intro here:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+OAuth2#JAX-RSOAuth2-OAuth2tokensandSOAPendpoints
Basically it will work with bearer tokens passed via Authorization headers as is, and can be easily customized to handle WS-Security binary tokens
I'm building a restful web-service based on Spring. I'm using Spring Security. It will be accessed only by desktop applications. Basically a machine-to-machine web-service.
I want a custom service that does the authentication. Then perform other, more sensitive operations based on the result of the authentication.
Another option is to send the credentials in the body of each request and basically do the authentication each time.
Logic says that the first approach would be the most efficient because there is quite some overhead in authenticating each and every time.
What do you suggest related to this? To go stateless or stateful? Are there major disadvantages to the stateful approach?
Up to this point I read some chapters from Java Web Services Up and Running
and also several questions from SO such as this.
The REST way to do this is, as stated in the links you provide, to authenticate on each request, and NOT to keep sessions.
As for authenticating with username/password on each request, it is secure if you can use ... a secure layer (https); else, the pair is sent in clear text and discoverable.
Another option is to use something like the AWS way to do it (Links to Amazon here and here, for example). Here for other explainations : buzzmedia and samritchie
Maybe OAuth is an option, but I don't have experience with it.
To start with REST Service (Client - Server) I will strongly recomend you to use Restlet
Authentication to this REST Service can be defined using ClientResource. Example :
private static ClientResource getClientResource(String uri) {
ClientResource clientResource = new ClientResource(uri);
clientResource.setChallengeResponse(ChallengeScheme.HTTP_BASIC,
"username", "password"
);
return clientResource;
}
I am building a web application with a services layer. The services layer is going to be built using a RESTful design. The thinking is that some time in the future we may build other applications (iPhone, Android, etc.) that use the same services layer as the web application. My question is this - how do I implement login? I think I am having trouble moving from a more traditional verb based design to a resource based design. If I was building this with SOAP I would probably have a method called Login. In REST I should have a resource. I am having difficulty understanding how I should construct my URI for a login. Should it be something like this:
http://myservice/{username}?p={password}
EDIT: The front end web application uses the traditional ASP.NET framework for authentication. However at some point in the authentication process I need to validate the supplied credentials. In a traditional web application I would do a database lookup. But in this scenario I am calling a service instead of doing a database lookup. So I need something in the service that will validate the supplied credentials. And in addition to validating the supplied credentials I probably also need some sort of information about the user after they have successfully authenticated - things like their full name, their ID, etc. I hope this makes the question clearer.
Or am I not thinking about this the right way? I feel like I am having difficulty describing my question correctly.
Corey
As S.Lott pointed out already, we have a two folded things here: Login and authentication
Authentication is out-of-scope here, as this is widely discussed and there is common agreement. However, what do we actually need for a client successfully authenticate itself against a RESTful web service? Right, some kind of token, let's call it access-token.
Client) So, all I need is an access-token, but how to get such RESTfully?
Server) Why not simply creating it?
Client) How comes?
Server) For me an access-token is nothing else than a resource. Thus, I'll create one for you in exchange for your username and password.
Thus, the server could offer the resource URL "/accesstokens", for POSTing the username and password to, returning the link to the newly created resource "/accesstokens/{accesstoken}".
Alternatively, you return a document containing the access-token and a href with the resource's link:
<access-token
id="{access token id goes here; e.g. GUID}"
href="/accesstokens/{id}"
/>
Most probably, you don't actually create the access-token as a subresource and thus, won't include its href in the response.
However, if you do so, the client could generate the link on its behalf or not? No!
Remember, truly RESTful web services link resources together in a way that the client can navigate itself without the need for generating any resource links.
The final question you probably have is if you should POST the username and password as a HTML form or as a document, e.g. XML or JSON - it depends... :-)
You don't "login". You "authenticate". World of difference.
You have lots of authentication alternatives.
HTTP Basic, Digest, NTLM and AWS S3 Authentication
HTTP Basic and Digest authentication. This uses the HTTP_AUTHORIZATION header. This is very nice, very simple. But can lead to a lot of traffic.
Username/Signature authentication. Sometimes called "ID and KEY" authentication. This can use a query string.
?username=this&signature=some-big-hex-digest
This is what places like Amazon use. The username is the "id". The "key" is a digest, similar to the one used for HTTP Digest authentication. Both sides have to agree on the digest to proceed.
Some kind of cookie-based authentication. OpenAM, for example, can be configured as an agent to authenticate and provide a cookie that your RESTful web server can then use. The client would authenticate first, and then provide the cookie with each RESTful request.
Great question, well posed. I really like Patrick's answer. I use something like
-/users/{username}/loginsession
With POST and GET being handled. So I post a new login session with credentials and I can then view the current session as a resource via the GET.
The resource is a login session, and that may have an access token or auth code, expiry, etc.
Oddly enough, my MVC caller must itself present a key/bearer token via a header to prove that it has the right to try and create new login sessions since the MVC site is a client of the API.
Edit
I think some other answers and comments here are solving the issue with an out-of-band shared secret and just authenticating with a header. That's fine in many situations or for service-to-service calls.
The other solution is to flow a token, OAuth or JWT or otherwise, which means the "login" has already taken place by another process, probably a normal login UI in a browser which is based around a form POST.
My answer is for the service that sits behind that UI, assuming you want login and auth and user management placed in a REST service and not in the site MVC code. It IS the user login service.
It also allows other services to "login" and get an expiring token, instead of using a pre-shared key, as well as test scripts in a CLI or Postman.
Since quite a bit has changed since 2011...
If you're open to using a 3rd party tool, and slightly deviating from REST slightly for the web UI, consider http://shiro.apache.org.
Shiro basically gives you a servlet filter purposed for authentication as well as authorization. You can utilize all of the login methods listed by #S.Lott, including a simple form based authentication.
Filter the rest URLs that require authentication, and Shiro will do the rest.
I'm currently using this in my own project and it has worked pretty well for me thus far.
Here's something else people may be interested in.
https://github.com/PE-INTERNATIONAL/shiro-jersey#readme
The first thing to understand about REST is that its a Token based resource access.Unlike traditional ways, access is granted based on token validation. In simple words if you have right token, you can access resources.Now there is lot of whole other stuff for token creation and manipulation.
For your first question, you can design a Restfull API. Credentials(Username and password) will be passed to your service layer.Service layer then validates these credentials and grant a token.Credentials can be either simple username/password or can be SSL certificates. SSL certificates uses the OAUTH protocol and are more secure.
You can design your URI like this-
URI for token request-> http://myservice/some-directory/token?
(You can pass Credentilals in this URI for Token)
To use this token for resource access you can add this [Authorization:Bearer (token)] to your http header.
This token can be utilized by the customer to access different component of your service layer. You can also change the expiry period of this token to prevent misuse.
For your second question one thing you can do is that you grant different token to access different resource components of your service layer. For this you can specify resource parameter in your token, and grand permission based on this field.
You can also follow these links for more information-
http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
I have faced the same problem before. Login does not translate nicely to resource based design.
The way I usually handle it is by having Login resource and passing username and password on the parameter string, basically doing
GET on http://myservice/login?u={username}&p={password}
The response is some kind of session or auth string that can then be passed to other APIs for validation.
An alternative to doing GET on the login resource is doing a POST, REST purists will probably not like me now :), and passing in the creds in the body. The response would be the same.
everyone.
I have a problem securing my REST web service. It's part of Java EE web application. To secure the pages I used login-config tag and set up "FORM" authentication. Now I don't know how to secure web services, because "FORM" is not appropriate for it and I can't have two login-config tags for app. I considered splitting into 2 apps, but don't think it's a good idea. Any suggestions?
This has info on how to create secured web services using NetBeans: http://netbeans.org/kb/docs/websvc/wsit.html
Many web service providers use an api key to authenticate access to the service. You may want to consider doing something similar for your service.
It is pretty common for the REST API to have a separate subpath - that way you can specify the auth constraint just to the URL's specific to your application and for the URI's corresponding to your REST API implement authentication using jersey OAuth filter or something else.
In case your app is all written in Jersey and you would like to expose exactly the same URI's for REST clients as well as browser (and differentiate just based on the requested media type), you can have a "login" URL (for displaying a login page) and only that you could protect using FORM authentication. Then again you would add Jersey OAuth filter (or other auth filter) which would not kick in unless there is OAuth header in the request, and another filter where you would check if ContainerRequest.getUserPrincipal() is null. If it is null, you could return Response.seeOther(UriBuilder.fromPath("/login").queryParam("redirect", request.getAbsolutePath()).build()).build() - that will redirect to the login (for oauth this would not kick in, since either the oauth request would succeed, or the previous filter would fail and return Unauthorized or Bad Request status codes). In the login resource you can use the redirect query parameter to redirect back to the original page once successfully logged in.