I just start work with SSO Saml and have some confuses that would like to clear.
- If I have to encode AuthnRequest with three mechanisms Deflate encode, Base64 encode, URL encodes. Do I have to use HTTP-Redirect to send message request?
- I refer to https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf page 16 for HTTP-Redirect Biding.
- If I using HTTP-Redirect Biding. Do I have to provide all 4 parameters SAMLRequest=value&RelayState=value&SigAlg=value&Signature=value or just two parameters SAMLRequest=value&RelayState=value I already have enough condition to send request to IdP.
If I have to encode AuthnRequest with three mechanisms Deflate encode,
Base64 encode, URL encodes. Do I have to use HTTP-Redirect to send
message request? - I refer to
https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
page 16 for HTTP-Redirect Biding. - If I using HTTP-Redirect Biding.
Yes, thats the requirement because in HTTP-Redirect you send the request as URL parameter hence need to minimize it in length/size.
Do I have to provide all 4 parameters
SAMLRequest=value&RelayState=value&SigAlg=value&Signature=value or
just two parameters SAMLRequest=value&RelayState=value I already have
enough condition to send request to IdP.
That depends on what is require by IDP but SAMLRequest is mandatory AFAIK.
Related
I have set up TLS to transfer passwords securely. Now I wonder if it is overkill to use form (POST) with enctype = "urlencoded" as also a layer of "protection"? (I know anyone can decode this). The other option is POST with enctype = "multipart" which is transparent / readable directly.
Appreciate all points of view
Encoding in this case is not a security feature (ie. it has nothing to do with security). It doesn't matter how you encode the password, the only purpose of such encoding is to be able to transmit it in a valid HTTP request, considering all the special characters it may have and so on. Security (encryption, server authentication, etc) is provided by TLS under HTTP.
I am new to RESTful services testing and got stuck where to establish connection to end point I need to pass Cookie. I have the parameter and Value but not sure how to pass Cookie manually (not through header or Groovy script) while hitting request.
TL;DR
Cookies are nothing but a header with a name cookie and header-value in a format name=value; anothername=anothervalue; yetanotherone=yetanothervalue;, as far as an http-request is concerned
Read On
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie
The Cookie HTTP request header contains stored HTTP cookies previously
sent by the server with the Set-Cookie header.
The Cookie header is optional and may be omitted if, for example, the
browser's privacy settings block cookies.
How to send Cookie
Just like any other header. Only condition is, Header name should be cookie and Header-value should be in name=value; anothername=anothervalue; yetanotherone=yetanothervalue; format.
Curl
curl -v --cookie "USER_TOKEN=my-most-secure-session-id" http://localhost:8080/
If you want your curl to read the cookie file and send it
use curl -c /path/to/cookiefile http://yourhost/
More here : https://curl.haxx.se/docs/http-cookies.html
How to send it using SoapUI
Sending cookie as request header in SOAP UI request for rest web service
Establish User session (Login) using chrome or firefox and goto the developer tab and copy the cookie value and send that along with your soapUI request as a header. (Congrats, you are hijacking your own session)
For any test that you need to pass the cookie around, in soapUI, go to the testcase options and turn on "maintain HTTP session".
http://www.soapui.org/soapui-projects/form-based-authentication.html
This is my google chrome developer tab which shows stackoverflow page's requestheaders
Just send the http header
Cookie: name=value
To the server
Why Authorization header is mostly used to send a bearer token to server? Why don't we send our authorization token as URL parameter or post it as json payload with the request body?
Headers are perfect to hold these data, they are independent of request type.
You could send Authorization token in body, even everything other like Content-Type, Content-Length, cache headers also but different request types (POST,GET..) could have different request body format. GET sends data using query parameters POST/PUT in encoded form in the body (with Content-Type: application/x-www-form-urlencoded to make server aware of incomming data format), Content-Type: application/json with JSON in body, XML and others. Things get more complicated on multipart requests (check this https://stackoverflow.com/a/19712083/1017363).
So as you can see authorization token in body or query makes things more complicated on client and server side. Client should know how to "fit" authorization token on every request and server should know then how to read this value.
I need to implement xsolla payment solution into my CakePHP 2.6 webapp.
By contract my site should communicate via REST with Xsolla.
Every request should contain Authorization Signature header which is sha1 hash of JSON body and the secret token.
Where is the right place to check Signature from xsolla in cakePHP?
Example request from xsolla:
URL: http://example.com/rest
Accept: application/json
Content-Type: application/json
Content-Length: 78
Authorization: Signature 8189119fb35327cdee7787990df41001c4bd9122
{"data":{"notification_type":"user_validation","user":{"id":"user_id"}}}
I need to check Authorization: Signature
The correct way of handling this in CakePHP is to implement a custom authorization handler. See the following links for reference, they explain what you need to do in great detail.
The basic procedure is to read the auth header and compare it against the user in your database. You'll do that in your custom authorization handler.
CakePHP 2.x
Authorization
Creating custom authorization handlers
CakePHP 3.x
Authorization
Creating custom authorization handlers
JWT Token Auth (check the code for reference)
The JWT auth is basically exactly doing what you want. The auth adapters aren't that much different. So you can backport that to CakePHP 2.x
We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they've identified the app_id and secret in the URL before the #. The remainder of the URI looks like what I would expect.
Is this valid? I thought maybe this is some weird cURL format I haven't seen before.
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/entity_locations/{locations_id}/
Just seeing if anyone has seen this format before?
A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.
The full scheme is:
scheme://username:password#domain:port/path?query_string#fragment_id
This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password#stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.
EDIT: a brief note about BasicAuth now you're asking - things go like this:
you make a request to http://johndoe:12345#service/api/foo/bar;
are credentials good? Ok, you get a 200 OK response with proper body;
are they not? You get a 401 Unauthorized response.
In the latter case, it's the browser [or any other program / script performing the request] that should prompt the user with the login popup.
Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent - it's just that every request to protected resources are featured with such header:
Authorization Basic base64encode(username:password)
Where base64encode is your custom way to encode the username:password string.