A client is trying to SSO into our app and the following error is thrown.
ERROR org.opensaml.common.binding.decoding.BaseSAMLMessageDecoder- SAML message intended destination endpoint
'https://client.ourapp.com/product:445/ProductName/AssertionConsumer' did not match the recipient endpoint
'https://client.ourapp.com/product:445/ProductName'
Notice the recipient endpoint is missing the '/AssertionConsumer'. Will appreciate if someone can guide on where I could be going wrong. Thanks
Related
I would like to set up my Service Provider (SP) for SP-initiated SSO.
When the user successfully logs in, I'm expecting the IdP to POST a SAML Assertion to my SP (is this called endpoint on my SP called an Assertion Consumer Service?).
What should I expect to happen when my SP and IdP are configured correctly but the user fails to authenticate – either with their primary credentials or MFA? Will the IdP POST a failure message to my SP?
If so, what is the conventional terminology for this payload? Is it still called a SAML Assertion but containing some kind of failure syntax differences or is it a totally different type of SAML payload, called something else? Do both success and failure payloads get sent to the same SP endpoint?
Thank you!
The thing you get back from the Identity Provider is always a SAML Response. If it's a successful response, you get an assertion. If it's a failed response, you get an error message passed from the IdP... And there's no real "standard" for those responses, other than the typical SAML message formatting.
Section 3.5.6 of the Binding spec describes the expectation for the POST profile. Each profile will provide for this, but as the SP, in most situations, you'll be using this binding.
Section 3.2.2 of Core defines the StatusResponseType - effectively, the status code of response that should be sent in various situations, the status message and status detail. It should be noted that most IdPs will simply return the urn:oasis:names:tc:SAML:2.0:status:AuthnFailed status code, and then maybe some additional detail in the status message or detail fields... But you cannot count on more than the code.
And yes, responses will always go to the typical SAML protocol endpoint, no matter their status.
I'm implementing a REST api and i'm in doubt about the response content in case of error. For instance, I use a jwt token for authentication. In case the client provides a wrong token, the server answers with a 401 status code with the following body
{
"status":"failed",
"details":"JWT token not valid"
}
In case the client doesn't provide the token, the server answers with a 401 status code with the following body
{
"status":"failed",
"details":"missing JWT token"
}
And so on.
These HTTP answers are informative, and they are useful when debugging. The problem is that an attacker now knows that the API uses a token, instead of basic authentication or other kind of authentication system.
For this reason, now I'm considering to answer only with the status code, and an empty body. This HTTP answer is not informative. An attacker doesn't know what's going on, and the same happens to me when debugging.
My question is: what is the best practice? Informative content or not? Is it necessary to create security with obscurity or not?
Thank you
If you return 401, the client will see what auth schemes are supported anyway:
"The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource." -- https://greenbytes.de/tech/webdav/rfc7235.html#status.401
I am asking maybe an open question about REST authentication practice. We use OpenID to authenticate with REST API. However there are some API where we do POST with body that also contain a secret (to support certain business rules). Now, if that secret is wrong am I still fine to return a 401 error? Does REST prescribe (like HTTP does) where token, password, secret should go in a REST call (e.g. always in HTTP Authorization header...)?
thanks
The 401 Unauthorized error is an HTTP status code that means the page you were trying to access cannot be loaded until you first log in with a valid user ID and password. If you have just logged in and received the 401 Unauthorized error, it means that the credentials you entered were invalid for some reason.
I am trying to add a new service via the CAS ReST Service. I have a few doubts
What should be attributeName and attributeValue ? I have kept it as "skip" and "enabled.+" respectively.
I am getting "Request is not authorized" when I give a request to add a service. I thought it could be because of TGT, but I found that TGT is not the issue here. How to solve this ?
Those are authorization-related attributes; Meaning the authenticated user must have that attribute/value before the request can be accepted.
I'm currently building a web application (utilizing Zend Framework) and have gotten some of the basic HTTP status codes down, such as:
404 on missing controller/action
500 on server exception
3xx returned by Apache
At the moment I have just implemented some basic ACL checking that the user is authorized to access a certain resource. It's implemented as a controller plugin, doing its thing on the routeShutdown event. It works like follows:
Get the role of the user. If the user is not logged in, assign the role of 'guest'
Check that the user's rule has access to the resource
2.1. If the does not have access to the resource and is a guest, save the resource he was trying to access, and forward him to a login prompt. Once he has supplied his credentials, he is redirected back to the original resource (via a HTTP redirect status code)
2.2. If the user is authenticated and the ACL denies him access to the resource, he is forwarded to the error controller, to an action I've called noPrivilegies.
If the user does have access, let the request continue as usual.
Now, my questions:
Can/should I use HTTP 401 for the 2.1 scenario? It's not like I want a WWW-Authenticate header field sent by the client. I just need him to login through my login-form. But I still think that the request wasn't a 200 OK, since he didn't get access to the requested resource.
Can/should I use HTTP 401 for the 2.2 scenario? Same reason here, WWW-Authenticate won't help. Perhaps it's better to use HTTP 403 Forbidden?
Do you recommend any other status codes for these two scenarios?
What other status codes do you usually return from your application, and when are they applicable?
Provided that the guest role may be allowed to perform some actions, then no 4xx response or other form of error is warranted at stage 2.1 of your process because not being logged in is not an error.
Neither 401 nor 403 is really ideal for an application-level "permission denied", but weighing 401's "The response MUST include a WWW-Authenticate header field" against 403's "Authorization will not help", I would say (and most cases I've encountered to date seem to agree) that 401 is the appropriate response if you are requesting HTTP level authentication before proceeding and 403 is appropriate in all other cases. So probably 403 in your case.
I think that 403 is the correct response. Per the HTTP spec, 401 is for cases where HTTP-level authentication is possible and required, 403 is for cases where the user does not have permission to access the resource. In the case of your app, the user has logged in, and it's unreasonable to expect that s/he will be able to use a different account.
Normally I don't ever use the status codes to report 'application' level authentication failures. That's generally reported via the app.
And it makes sense to do that; because they can access the 'page' from a 'http' sense; they just can't access your applications processing of that page, if that makes sense.
What I'm saying is generally you don't worry about the codes, or set them yourself at all, when returning data to the client. Leave it to the webserver and provide an 'abstracted' method of responding; i.e. the typical 'invalid username or password' page, etc.
Just my view, though.
i've recently implemented something that works in a similar way, we return a 401 response when a user has to login and a 403 if after login they've tried accessing something that they don't have permission to access.
you can also set the reason phrase in the http response to something to denote the reason for the failure.
Even not specifically stated in HTTP spec, the common practice is
401 - For authentication error
403 - For authorization error
Try not to use 401 if you don't want authenticate user. I recently encountered a problem with a HTTP client (not one of the popular browsers) that it logs an error when it sees 401 but not WWW-Authenticate header. Granted this is a bug on the client side but it shows how people perceives 401.