I am using the mod auth mellon on apache for authentication on my SP.
I have added on the SP metadata the directive to require signed resonses
<SPSSODescriptor
AuthnRequestsSigned="true"
WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
>
But when receiving the response from the IdP I see that removing the signature does not render the response not-accepted, so I am still able to login.
The documentation for Mellon is somewhat outdated and other than the readme.doc there are not a lot of resources.
**Does anyone know how I can force mellon to check the SAML Response signature?
**
I tried already searching on SO for this. I made sure that all the SAML Responses had a signature value in their payload. I made sure that the signature value matched the public key value of the IDP.
Related
I have a backend service configured as a subdirectory behind a reverse proxy. The backend has its own auth scheme, and it relies on the authorization header being formatted as
Bearer <JWT Token>
in order to validate a session. Unfortunately, the backend reveals what it is to any curious eyes, and doesn't keep any record of auth attempts/failures to filter with, for example, fail2ban.
I would like to hide the backend behind basic auth, so the page details are only loaded for authorized users, and so that I can monitor auth attempts/failures across all my backends with a simplified fail2ban filter.
The problem I'm encountering, is that in order for the client's requests to reach the backend, once it's secured behind basic auth, the Authorization header needs to be formatted as
Basic <base64-encoded username:pass pair>
The moment the client sets this header, though, the backend is unreachable. The backend and the client also have quite a bit of back-and-forth communication, and from what I can tell <UserToken> is dynamically generated for each login session.
I've tried
proxy_set_header Authorization <A statically generated and set JWT Token for testing>
In the location block of the backend. However, at some point in the transactions that result between client and backend, the Authorization header goes from
Basic (with backend asking for credentials)-> Bearer (backend is authenticated and loads a few resources until...) -> Basic (backend is now logged out and reauthenticating causes an infinite loop)
Essentially, as soon as the Authentication header is reset by the client to authenticate with basic auth, presumably for the client's next request, the backend becomes inaccessible. I would like a way to dynamically maintain two Authorization headers with nginx, if such a configuration is possible, and set the header appropriately according to where in the chain between client, proxy, and backend the request occurs.
I've also tried to experiment a little bit with a mapping like:
map $http_authorization $origin_auth {
"Bearer" $http_authorization;
}
and then adding this directive inside the server block:
add_header my-header $origin_auth always;
Just to see if I could store the header for retrieval on one of the client's future requests, or something... scrolling through dev tools though, to examine the header fields, "my-header" never assumes the value of the backend's expected authorization header.
I don't have enough experience with either the http protocol, or nginx, to know if the thing I want to accomplish is even possible, and I haven't found much help in other posts. I have tried throwing about 3 dozen hours of my life at the problem though, without any luck. Any help would be very welcome and appreciated.
As per the documents received writing down the flow of authorization for version 4.0:
1. call authorize service to get the authorization code back.
2. read the 'code' value for the authorization_code.
3. use this authorization_code to get 'access_token' using '4.0/oauth/token'.
4. for the subsequent calls use 'access_token'.
Please confirm if my understanding above is correct.
My question:
- What will happen when access_token expires? Do we need to go to above flow again?
- the URLs are https does it need certificates?
- what will be the redirect_uri if i want to test in my dev?
I suggest reading a bit about OAuth 2.0 flow. Here's a decent article/example that I would start with from Digital Ocean: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
But to answer your specific questions:
when the access_token expires you need to make an additional request to Social Tables with the refresh_token -- here's an example: click here. In short, yes you need to use the refresh token to get a new access token which you'll use for subsequent requests
No, you do not need to configure any certificates on your end. These are done via SSL+HTTPS and are ready to go.
The redirect_url for local development can be set to your local running server. You can set it to http://localhost:<port> and that will work just fine.
I've searched all over (including here on Stackoverflow) for how to use the Magento REST API. I need help on getting an Unauthorized Request Token (the first step)
On the Magento setup I'm using the REST API is working for GET Products for Guests so I know that is not [the problem][1]
I have setup an OAuth Consumer for the above URL and have both the consumer key and secret. I can't figure out what URL to use for the Callback URL.
First, I'm stuck and don't know what I should use as the Callback URL when setting up the consumer. It is an optional field in Magento
I'm testing with the Firefox REST Client as per http://www.magentocommerce.com/api/rest/testing_rest_resources.html
Next with the Firefox REST client I can't get started by getting an Unauthorized Request Token. According the above URL I should have the oauth_callback URI in the header.
The following request parameters should be present in the Authorization header:
oauth_callback - an URI to which the Service Provider will redirect the resource owner (user) after the authorization is complete.
oauth_consumer_key - the Consumer Key value, retrieved after the registration of the application.
oauth_nonce - a random value, uniquely generated by the application.
oauth_signature_method - name of the signature method used to sign the request. Can have one of the following values: HMAC-SHA1, RSA-SHA1, and PLAINTEXT.
oauth_signature - a generated value (signature).
oauth_timestamp - a positive integer, expressed in the number of seconds since January 1, 1970 00:00:00 GMT.
oauth_version - OAuth version.
What is the oauth_callback URI when using the above URL?
When I try a POST to Endpoint: /oauth/initiate
I get:
oauth_problem=parameter_absent&oauth_parameters_absent=oauth_callback
I'm lost and don't know what else to try. I'm a novice programmer and new to the Magento REST API...so keep that mind. It may be that I'm just missing the obvious.
Anyone who is interested in helping me figure this out here are the Consumer key and the secret.
key: d2f4a7cc63715f98d12db2c6db63cfba
secrect: 8347474102cbf2d40b06f9d76f281e73
The URL is: http://temp.pramier.com
This is from a test install so I'm not worried about giving out the key and secrect
Pass the oauth_callback like http://temp.pramier.com/admin.
You is in this step:
Getting an Unauthorized Request Token
The first step to authenticate the user is to retrieve a Request Token from Magento. This is a temporary token that will be exchanged for the Access Token.
Endpoint: /oauth/initiate
Description: The first step of authentication. Allows you to obtain the Request Token used for the rest of the authentication process.
Method: POST
Returns: Request Token
Sample Response: oauth_token=4cqw0r7vo0s5goyyqnjb72sqj3vxwr0h&oauth_token_secret=rig3x3j5a9z5j6d4ubjwyf9f1l21itrr&oauth_callback_confirmed=true
You should continue to get the token.
This is the best (and official) tutorial:
http://devdocs.magento.com/guides/m1x/api/rest/authentication/oauth_authentication.html#OAuthAuthentication-UsingOAuth
I am not sure what programming language you are using, but the API lists the code for authenticating and retrieving products in php on the bottom.
I just started working on this in ruby using the code here.
#consumer=OAuth::Consumer.new auth["consumer_key"],
auth["consumer_secret"],
{:site=>"your-site-here"}
#request_token = #consumer.get_request_token
Let me know if I misunderstood your question or wasn't clear in my explanation.
Please follow those instructions here:
http://inchoo.net/magento/configure-magento-rest-and-oauth-settings/
After that, follow these steps:
http://www.aschroder.com/2012/04/introduction-to-the-magento-rest-apis-with-oauth-in-version-1-7/
At the beginning of the article, the writer asks to use a Ruby program called oAuth. If you are using Linux, put these commands into the command line to install Ruby and oAuth:
sudo apt-get install ruby
and
sudo gem install oauth
Beware, if you put exactly this:
--authorize-url http://www.yourstore.com/magento/oauth/authorize \
You'll get a permissions error when you'll want to login. You should replace this by:
--authorize-url http://www.yourstore.com/magento/admin/oauth_authorize \
Everything should go smoothly.
I always have this error when I follow ryan's tutorial to how to use Doorkeeper to protect rest API:
OAuth2::Error: invalid_grant: The provided authorization grant is
invalid, expired, revoked, does not match the redirection URI used in
the authorization request, or was issued to another client.
{"error":"invalid_grant","error_description":"The provided
authorization grant is invalid, expired, revoked, does not match the
redirection URI used in the authorization request, or was issued to
another client."}
when I'm in the phase of parsing token. What is the problem and how I can fix this ?
I have an habit of adjusting my time 20 minutes ahead and it's the source of this problem. Change back the time by synchronizing, now everything works :)
Should a failed login attempt result in a HTTP 401 response? Doesn't seem like all the major sites do this.
I think it depends on the type of authentication in use.
If you look at the same source that #Jan Vorcak cited (RFC 2616), it says that the 401 response "MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource." That refers (as has been posted since I started typing this answer) to the HTTP authentication schemes based on RFC 2617. Few sites intended for the general public use seem to use these authentication methods anymore. So, since the WWW-Authenticate header is meaningless, it should not be included, which means that returning a 401 error violates RFC 2616.
So, in most cases, I think the answer is "no."
Only if your site uses HTTP-code based authentication schemes like the basic authentication or digest authentication.
http://en.wikipedia.org/wiki/Basic_access_authentication
http://en.wikipedia.org/wiki/Digest_access_authentication
There are other obvious alternatives, like relying on custom cookies and using 302 to redirect to a login page. The 302-based authentication schemes are probably used most often.