a customer of ours recently uses ADFS on their Project Server 2016 environment. We have some solutions deployed that communicate with PSI. After using ADFS, the PSI however cannot be reached. We receive following error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was ''.
In ULS, I found following entries:
Claims Authentication 0 Unexpected User-Agent is empty
...
Authentication Authorization agb9s Medium Non-OAuth request. IsAuthenticated=False, UserIdentityName=, ClaimsCount=0
...
Claims Authentication af30r Medium Multiauth SPWebApplication with widnows enabled and MS-OFBA accepted was set to false for the request url 'https://***/PPM/_vti_bin/PSI/ProjectServer.svc'.
General b6p2 Medium Sending HTTP response 401 - text/plain:401 UNAUTHORIZED.
Does anyone have an idea how to solve this? Is there a sample available on how to deal with ADFS and PSI?
Related
I'm making an auth POST request to the https://example.my.workfront.com/integrations/oauth2/api/v1/jwt/exchange (note: actual request has 'example.my' subdomain replaced with the real Workfront subdomain for my org) endpoint with the required client_id, client_secret, and jwt_token values but receiving the following 404 response and error message in the Response:
{"statusCode":404,"error":true,"type":"Not Found","message":"Invalid Host"}
I searched the API docs and Workfront forum for any additional information on what could cause the error but had no luck. Does anyone know what is causing this error?
For context, this request seems to work fine from Postman on my local machine (i.e. auth token is returned) but fails on the server that is being used for this machine to machine application.
The issue was that the request to the Workfront API was including the port in the host Header value, i.e. example.my.workfront.com:443.
Excluding the port so the host Header value is in the format example.my.workfront.com resolved the issue and provided the expected 200 response with auth token.
I wanted to have digest authentication Authorization header added in very http request and hence added HTTP Authorization Manager under thread group. I added URL,username, password, domain, realm (both to same name) and selected BASIC_DIGEST as the option (I wanted only digest authentication).
I also uncommented http.authentication.preemptive$Boolean=true in httpclient.parameters and uncommented httpclient.parameters.file=C:\apache-jmeter-2.12\apache-jmeter2.12\bin\httpclient.parameters in jmeter.properties file.
After done, I closed my jmeter and started it again. When I gave a run and did a wireshark capture, I figured out that GET was sent with NO Authorization header, and server sends a 401 response and jmeter closes socket and fails the case.
I am not sure what I have done wrong. Awaiting for your comments.
JMeter Logs:
2014/11/20 13:19:35 INFO - jmeter.threads.JMeterThread: Thread started: Thread Group 1-1
2014/11/20 13:19:35 INFO - org.apache.commons.httpclient.auth.AuthChallengeProcessor: digest authentication scheme selected
2014/11/20 13:19:35 INFO - org.apache.commons.httpclient.HttpMethodDirector: No credentials available for DIGEST 'users#perf.tb.com'#192.168.100.30:80
Realm should not be required for digest authentication, domain is quite enough
Make sure that you're using either HttpClient3.1 or HttpClient4 implementation
See Windows Authentication with Apache JMeter guide for details on how to configure HTTP Authorization Manager for digest and kerberos authentication types
I'm working on an application that should be available to intranet users running under their own account (Windows authentication). This is easily configured and works.
Now if users are not logged in to the domain (because they are off site or on a device that is not logged in) they should still be able to use the application, minus some personalized functionality.
So to sum that up, this is what I would like to happen:
User opens the application. If windows credentials are available the browser sents them to IIS.
If the users credentials are recieved, the application runs under these credentials (I've got that covered).
If the users credentials are not recieved, the application runs under the IIS anonymous account and personalized functionality is turned off (I've got that covered as well).
What I can't get to work is to optionally send the credentials. If I turn on windows authentication, I'll be logged in, which is fine. However if I try to access the site without sending credentials I'll get a 401, which makes sense. So I turn on anonymous authentication and now credentials are never sent.
This actually makes sense, because IIS never requests for authentication from the browser. The question is, how do I make this scenario work?
You are right on your analysis.
HTTP authentication schemes are :
Anonymous access
Challenge-Response authentications
Negotiate (Kerberos)
NTLM
Digest
Basic authentication
On IIS (and most HTTP servers), the default authentication process respect the order above. ie. If anonymous access succeeded (will not get into details here) others authentication providers are ignored even if they are enabled.
HTTP 401 Challenge
If you want to manage multiple authentication methods and providers you have to use a mechanism which refuse the credentials when you consider them invalid. You can achieve this by sending 401 Responses. This is called HTTP 401 Challenge.
The idea is to tell to the client (browser) that the credentials used for the requested resource are refused.
Depending on the scenario and the client configuration, the client may handle an authentication. And in this case the authentication process may vary : Challenge-Response providers needs a certain number of exchanges to valid the credentials.
Anyway, in your case, with anonymous access enabled, the first 401 response will be interpreted by the browser as "This request requires an authentication". The server automatically include the supported authentication providers in the response header if they are enabled on the server side.
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/7.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="+Upgraded+v1b3a89710edce01754fd608...",charset=utf-8,realm="Digest"
WWW-Authenticate: Basic realm="host"
X-Powered-By: ASP.NET
Content-Length: 0
Proxy-Support: Session-Based-Authentication
If your browser is correctly configured to send the credentials for the zone of your web application (you said so), it'll automatically use the first authentication provider it knows (NTLM for example) and re-process the request with the credentials it knows (Windows credentials in your case).
GET http://host/yourpage.aspx HTTP/1.1
Accept-Encoding: gzip, deflate
Authorization: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
Connection: Keep-Alive
When the authentication process fail, the server automatically send a 403 Forbidden response to the client to avoid too much traffic. A 403 response stops the challenge. The good news is it takes some challenge to happen : more than 4.
And usually, an HTTP authentication challenge needs near to 3 Challenge-Response maximum to succeed (3 for NTLM and 2 for Negotiate -Kerberos-).
Since you allow anonymous access, the server will not block the client requests and your pages will be called with anonymous credentials. You can still interact with your client in your page by setting yourself the HTTP Response Code. As already said, its only works if you enable another authentication provider in addition to Anonymous.
So the trick is to handle it with a counter on your server side and say "if my auth session/cookie counter is more than 3, my client can't authenticate with the server. Let's say he is anonymous".
Some Code
I didn't do exactly what you need but you can adapt my code :
int i = 3;
int j = 0;
HttpContext httpContext = HttpContext.Current;
// Record authentication process
HttpCookie httpCookie2 = httpContext.Request.Cookies["loginAttemptCount"];
if (httpCookie2 == null || httpCookie2.Value == String.Empty)
{
httpCookie2 = new HttpCookie("loginAttemptCount");
}
else
{
j = Int32.Parse(httpCookie2.Value, System.Globalization.CultureInfo.InvariantCulture);
}
j = (j + 1) % i;
string user = Request.ServerVariables["LOGON_USER"];
// Send 401 responses to authenticate the user
if (j != 0 && user == String.Empty)
{
httpCookie2.Value = j.ToString(System.Globalization.CultureInfo.InvariantCulture);
httpContext.Response.Cookies.Add(httpCookie2);
Response.StatusCode = 401;
return;
}
httpCookie2.Value = String.Empty;
httpContext.Response.Cookies.Add(httpCookie2);
If needed, you can check the authorization provider in the Authorization header.
Request.Headers["Authorization"]
You can use Fiddler to trace your HTTP headers.
Hope it's clear enough.
We have a secured WCF service with WsHttpBinding, Client & Server certificates & transport security with Claim Based Authorization.
Everything works fine 50 % of the time. When we do request to a secure endpoint, we get the correct response. But if we send the same request again immidiatly after the first we get the following response:
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
If we then send a request again, we get normal behaviour. So the odd requests work and the even not.
But after some more investigation in the problem. We noticed that if there is at least 1:40 minutes between the previous request, we don't get the error response.
What we can confirm from the debugger and logging. The client sends the credentials to the service. We don't enter System.ServiceModel if we have the Authentication response. In the IIS trace logs we get this on a good request:
Authentication: SSL/PCT
User from token: Domain\CertifacteUserName
and this on a bad request:
Authentication: NOT_AVAILABLE
User from token:
Also in the IIS Trace logging. If we send the second request, we see that the ConnId and RawConnId are the same on both requests. And if we make multiple successful request (By allowing some time between requests) they are different for each request.
It seems to me IIS is not getting the Credentials we send, when they are there. Is this due to caching? Or something else? Does anyone has a solution.
This is a conceptual question.
I have a client (mobile) application which needs to support a login action against a RESTful web service. Because the web service is RESTful, this amounts to the client accepting a username/password from the user, verifying that username/password with the service, and then just remembering to send that username/password with all subsequent requests.
All other responses in this web service are provided in a JSON format.
The question is, when I query the web service simply to find out whether a given username/password are valid, should the web service always respond with JSON data telling me its successful or unsuccessful, or should it return HTTP 200 on good credentials and HTTP 401 on bad credentials.
The reason I ask is that some other RESTful services use 401 for bad credentials even when you're just asking if the credentials are valid. However, my understanding of 401 responses are that they represent a resource that you are not supposed to have access to without valid credentials. But the login resource SHOULD be accessible to anyone because the entire purpose of the login resource is to tell you if your credentials are valid.
Put another way, it seems to me that a request like:
myservice.com/this/is/a/user/action
should return 401 if bad credentials are provided. But a request like:
myservice.com/are/these/credentials/valid
should never return 401 because that particular URL (request) is authorized with or without valid credentials.
I'd like to hear some justified opinions one way or the other on this. What is the standard way of handling this, and is the standard way of handling this logically appropriate?
First off. 401 is the proper response code to send when a failed login has happened.
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
Your confusion about, myservice.com/are/these/credentials/valid sending back 401 when you just do a check, I think is based on the fact that doing boolean requests in REST often is wrong by the RESTful constraints. Every request should return a resource. Doing boolean questions in a RESTful service is a slippery sloop down to RPC.
Now I don't know how the services that you looked on are behaving. But a good way of solving this is to have something like an Account object, that you try to GET. If your credentials are correct, you will get the Account object, if you don't want to waste bandwidth just to do a "check" you can do a HEAD on the same resource.
An Account Object is also a nice place to store all those pesky boolean values that otherwise would be tricky to create individual resources for.
401 should be sent only when the request needs authorization header field and authorization fails. Since the Login API doesn't require authorization, hence 401 is the wrong error code in my opinion
As per the standard here https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
*10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].*
If the 401 response code is misleading for user authentication, the API can send HTTP status code 200 OK for both successful and failed authentication, but set a custom header on the authentication successful response and omit that header on failed logins.
The client can check if the header exists or not and decide the action.
Example: SpringBoot API Response
The call to OK when login is successful sets the header "gotyouin" with a value (anything). Call to failed does not add the header and client can treat this as a failed login attempt.
public class LoginResponseEntityHelper {
public static ResponseEntity<?> ok(String token) {
return ResponseEntity.status(HttpStatus.OK).header("gotyouin", token).body(null);
}
public static ResponseEntity<?> failed() {
return ResponseEntity.status(HttpStatus.OK).body(null);
}}
It is logical to use 401 http status code when access to a resource is denied because the request lacks or has incorrect credentials. And when correct credentials are provided, the request should complete successfully granting access to the protected resource.
Applicable for your case: myservice.com/this/is/a/user/action.
Maybe we should be clear about this credentials
In most secure applications, credentials are needed to access protected resource(s). These credentials can be sent along every request via HTTP header. Specifically the Authorization Header.
Therefore the Authorization header contains credentials to allow a user to access protected resource(s).
Remember that a user who was verified successfully as an authorized user(successful login), is the one given this priviledged credentials to allow for access on protected resources on the server.
From the server point of view, a HTTP request targeting a protected resource yet it is lacking credentials or containing invalid credentials may cause to validly send back 401 response code.
Therefore the Login API should not send a 401 response code because of a failed login attempt. It is misleading. Reasoning out that you are requesting to the server application via the Login API to grant you with credentials required to access resources that are protected. By itself, the Login API is not a protected resource.
So what is the correct response status?
Well I will opine towards sending back a 400 response code because a failed login attempt is a client error who is at fault for not providing the correct username or password.
According to RFC standards about 400 code:
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)
Again I will reiterate that failed login is a client error due to providing details that are incorrect. Sending back a 400 doesn't have to mean that the request syntax is malformed. But a malformed syntax is one of the reasons.
Sending a 401 would really be misleading as the user doesn't need to provide authentication information to access the login API.