I developed an application in java that needs to consume a set of webservices provided by a provider.
Basically I need to call a first rest webservice to connect to the system, in which I pass username and password in the body of the post rest call.
Without using proxies I can make a second rest call without passing username and password, the webservice provider recognises me.
But when I use a proxy this second call does not work any more, I get an HTTP 401 error.
Notice that the first connect call works well also with the proxy.
Is there something conceptual that I'm missing?
Anyone knows what is happening?
Thank you
If you're making only a single login request and then making follow up requests which do not supply credentials, the service you are consuming probably is using cookies to track a user session.
When you put a proxy between yourself and that service, if the proxy is not forwarding all of your HTTP header information (where the cookie is probably being exchanged with the service), then the service will no longer recognize your session and consider you unauthorized
You may need to better understand how the service is maintaining your session (is it using Set-Cookie headers that it expects you to send back?) And you need to understand if the proxy you are using is forwarding all of your headers to the service
Related
I am trying to figure out a clean way to retrieve a cookie using httpcomponents version 4.5.13 (JSessionID) from a login endpoint of the server https://example.com/login which takes a username/password and responds with the JSessionID that should be used for authentication and use the same cookie in the actual call to the endpoint that I would to execute https://example.com/search.
The standard way to do it is with two separate requests which is a lot more verbose. Is there an interceptor that can be used to achieve this?
I got a Jersey Grizzly REST server running. Now i am receiving receiveing an URL from Microsoft with an Access Token however this access token is placed as an parameter after a # Symbol.
https://myURL.com/getToken/pathParam/#access_token=QWERwtrrgertWRDGTGHssef....
When i receive the Request from MS i cant read out the access token by any means, since it is filtered out. Is there a configuration where I can stop this and get the token as a param ?
From the looks of the fragment, it appears you are trying to accomplish an OAuth flow. The problem I see is that you are trying to implement a flow that is meant for the client side (or more correctly, user-agent side), and then trying to access the fragment on the server, which is meant to be interpreted on the user-agent side.
The #access_token.. tells me you are trying to implement the Implicit Grant. This is not recommended if you have access to the more common Authorization Code Grant. I don't know what Microsoft service you are using, but if they offer the Implicit Grant, then they should also offer the Authorization Code Grant, which is actually the most common in all of the Grant types.
If you want to stick with the Implicit Grant, then you will need to actually handle the redirect from the client (user-agent) side, meaning get your hands into writing some Javascript to postback the token to the server. You can see an example here.
I personally wouldn't recommend it. You can have a look at the Jersey OAuth 2.0 client. It will help with implementing the Authorization Code flow.
i've made a webservice where i expose some methods:
/Orders
/Plans
etc.
I would like to add authentication for every method. I would like to pass this information on HEADER request.
So, for every request i will send my username/password and the webservice will reply me with the information that i've request (if my username/password is correct), 405 or else if i cant access to this.
I would like to implement a mechanism like Parse.com.
In this webservice (reading the doc) for every rerquest i send API KEY and CLIENT KEY. I would like to do the same in my RESTful Web Service. I will access it from iPhone/Android application, but this isnt a problem.
The problem is... how secure all my methods ?
SSL, with a filter to check for the existence and validity of the keys.
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 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)