"wreply" is an optional parameter according to "WS-Federation: Passive Requestor Profile", and it defines the RP endpoint that handles the response.
So, how could the STS decide to where the response should be sent when that parameter does not come in the request?
As far as I understand, the only solution for this is to make it mandatory to provide a redirect URL at the time of RP registration in STS. And then send the response to 'wreply' if it comes in the request, else send to the registered endpoint.
Is that the normal approach?
Related
I'm trying to figure out if it is and how possible to initiate a connection with Authorization that avoids getting a 401 back from the server on the initial call.
According to the RFC (https://www.ietf.org/rfc/rfc4559.txt, end of section 4.2), the client should be able to send, with the initial request, an Authorization header containing a token, but for me that doesn't work. I've tried sending the same token (seems to be always the same) that is usually sent as a response to the first 401, but no luck.
Is there something in the configuration that needs to be changed to allow such behavior or do I need a different token?
The title sums it all up nicely. I'm asking for the conditions that should be met so Spring decides to send back a Set-Cookie:XSRF-TOKEN=... response header.
I can see that lots of my requests are getting back responses with such header while it is not needed. For instance, when I send a GET request it gets a response with that header set even though I had set the X-XSRF-TOKEN for the request. But for the POST request having the mentioned request header will stop Spring from sending back the set-cookie header. So I wonder what are the conditions that should be met so Spring decides to send back one.
I spent some time tracing Spring Security's source code and I managed to find out the answer myself.
First of all, I didn't know how CSRF works and tracing the code helped me understand it completely. And I think this is something worth knowing. Here's the scenario of requests and responses sent and received from CSRF point of view:
The first request is sent to the server. Since it's the first one, it has no cookie or header set.
Regardless of the request's method, the server (in here Spring Security) looks into the incoming request. If there's no cookie sent to the server under the name XSRF-TOKEN, it will generate a SET COOKIE header on the response's way back.
The client receives the cookie and for the second request, it will add a header to the request under the name X-XSRF-TOKEN set to the same value as the cookie received. Of course, the cookie will be sent to the server with the second request automatically.
When the server receives the second request, this time it has a XSRF-TOKEN cookie, so it will look for a X-XSRF-TOKEN header and the request is considered valid only if these two strings match.
And as for the answer to my question, as I mentioned in step two, the cookie is generated if there's no cookie sent (with XSRF-TOKEN name) to the server. And it does not rely on any other factor - what so ever!
I want to customise OAuth Endpoint URI's.
I want to sent parameters in post body instead of query params.
now my request is like -
example.com/oauth/token?grant_type=password&client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}&username={USERNAME}&password={PASSWORD}
But I want it like this.
example.com/oauth/token
Request body -
{
grant_type=password,
client_id={CLIENT_ID},
client_secret={CLIENT_SECRET},
username={USERNAME},
password={PASSWORD}
}
How should I do it?
The token endpoint of a properly-implemented authorization server does NOT accept GET requests because RFC 6749, "3.2. Token Endpoint" says as follows:
The client MUST use the HTTP "POST" method when making access token requests.
So, your authorization server's token endpoint should reject GET requests.
RFC 6749, "4.3. Resource Owner Password Credentials Grant" says that request parameters of a token request using Resource Owner Password Credentials flow should be embedded in the request body in the format of "application/x-www-form-urlencoded". The following is an excerpt from "4.3.2. Access Token Request".
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
Therefore, you don't have to customize your authorization server. If the server is implemented correctly, its token endpoint accepts POST requests.
The token endpoint created by spring-oauth2 already deals with POST as well.
It would be hard to customize it to accept a JSON request body, because the TokenEndpoint class expects all the params as #RequestParam params.
However, if your concern is about security (as HTTPs does not secure query parameters) you indeed can send the request parameters through post. It is just a matter of sending the request in the form "form-data" or "x-www-form-urlencoded". These are 2 ways of sending arbitrary key-value parameters in the request body, in a way that appears to the server as they are regular request parameters. So it is a matter of making your client using this.
Also, note that in spring-oauth2 it is possible to disable the GET endpoint, this way forcing your clients to use POST with one of the ways above.
I have a server in which the client can register itself as a device (like a mobile device). For the registration, the device must be associated with another resource (say an user) which is already registered on the server. To do that, the client sends a Http Post request to the server, with two params, its own ID and the associated resource ID.
I need to choose an Http Status code to return when the client ask the server to do some procedure and one of the resources indicated in the parameters are not found.
I suggested 404, but my professor said that 404 is used the resource associated to the URI is not found, not when you submit a well-formed request with bad parameters.
What is the most suitable http status and why would you choose?
In my opinion, it fits to:
400 - Bad Request
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
OR
403 - Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
Ref: fc2616
I would use 403 'Forbidden' - meaning, you are forbidden from accessing the page with the request you have sent
How oData or AJAX services should respond when the authentication cookie is expired and it's time to renew?
What should the server send to the client when
An oData or AJAX service access is forbidden (access denied)
When the session credentials are stale, and need to be renewed, perhaps by redirecting to an ADFS, OpenID, or Azure ACS IDP
Just looking in Wikipedia lets me guess that I should send some version of 403.x for the first scenario, and a 401 for the second scenario.
Please confirm if the above is correct, and what I should include in the response header and body as well.
Some examples I assume to be incorrect do the following:
Silently error out the AJAX service and return no data
Attempt to redirect the AJAX call to the IDP
Send error text to the client that is not in JSON format
its always safe to play with the HTTP Status codes instead of cooking up your own tokens or anything of that sort.
Since the fundamentals of OData is to make it possible for any client which knows how to communicate HTTP, it makes sense to play around the HTTP status code. The clients will decide what to do on a particular status code.
HTTP Status Codes are the way to go. OData specifically doesn't define anything that is already implemented at a lower level (such as security and authentication.)
401 is for Unauthenticated, 403 is for Unauthorized. For secnario 1 you only say "Access denied" but not why you're denying access. Is the user not authenticated? Then return 401. Is the user authenticated but lacking privileges? Then return 403.
For scenario 2, I would agree, return a detailed 401 status (i.e. with a valid "WWW-Authenticate" header for your authentication provider.)
The Wikipedia article I recommend starting at (you may have already found this) is: https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_status_codes
Hope this helps someone. :-)