What is effect of negotiateServiceCredential=false in WCF - wcf-security

I have a WCF service with message security with username type. I have added a service level certificate. I set the negotiateServiceCredential setting as false in service config.
Then I add reference of the service in console application. The console app config file now has the settings including the negotiate tag value as false. Client config also has a encoded certificate value in the config file. Now when I run the application and it seems to be fine.
My doubt is what is the effect of setting the negotiateServiceCredential to false as the application is calling the WCF successfully. I have not set the certificate either in code or config for the console application.

Related

HttpRequestMessage.GetClientCertificate() returns null in ASP Web API DelegatingHandler

I have an ASP Web Api (.Net Framework 4.6.1) which accepts client certificates. The requirement is to send a custom validation message in the response of a request that has an invalid certificate.
For example, if the certificate is missing I should send back "Client certificate is missing", if the OCSP validation fails, I should send back "Certificate has been revoked", etc.
This is the code:
public class CertificateMessageHandler : DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
CancellationToken cancellationToken)
{
var certificate = request.GetClientCertificate();
}
}
I have a client application where I select what certificate I want to use, and it does a request to the web api application (which is hosted on another machine). If the certificate is valid, then request.GetClientCertificates() returns the certificate, otherwise, if the certificate is expired or self-signed, request.GetClientCertificates() return null.
I have disable the automatic CLR validation by the IIS:
netsh http show sslcert
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 e104e... appid={4dc3e181-...} certstorename=My verifyclientcertrevocation=disable
I have set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo\0.0.0.0:443\DefaultSslCertCheckMode=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList=0
None of the above settings worked.
Note: a 3rd party that uses the web app might send a self-signed certificate and the business logic should reject the request for such certificates, therefore, the inclusion of the CA, that was used to sign the certificate, in the Trusted Root Store, isn't possible.
Any help is appreciated on how to get the client certificate from the request.
EDIT: it seems that the module "IIS Web Core" validates the certificate against the certificates store way before the request is "forwarded" by IIS to my application:
You could try to check the below settings:
set the iis SSL setting to accept:
and set below code in web.config file:
<iisClientCertificateMappingAuthentication enabled="true">
</iisClientCertificateMappingAuthentication>
Edit:
Asp.net Core is a framework and Hostable Web Core (known as HWC) is a new concept in IIS to host a website/web services inside your own process. In short a smaller hosted version of IIS (an IIS express edition?).
This is accomplished by making a LoadLibrary call to load hwebcore.dll (%systemdrive%\Windows\System32\inetsrv\hwebcore.dll)
Try to disable the Hostable Web Core feature by following below steps:
Open control panel.
Click on “Turn Windows features on or off” from the left pane.
Locate Internet Information Services(IIS) Hostable Web Core from the list and uncheck the checkbox.
restart iis after doing changes.
https://blogs.iis.net/sukesh/iis7-hosted-web-core-custom-service-webcoreservice
refer this below links or more detail:
HttpRequestMessage.GetClientCertificate() returns null in Web API
How to use a client certificate to authenticate and authorize in a Web API
Client Authentication for WebAPI 2

Error Service 'LogService.LogService' has zero application (non-infrastructure) endpoints

I have a asp.net aspx web application projects where i have LogService.svc file which I believed is wcf service file.
When i run the application in Local IIS 'http://localhost/LogService/LogService.svc' it does not show error message while
when i publish the same project in the Test Server. It shows error 'Service 'LogService.LogService' has zero application (non-infrastructure) endpoints. '
Service ‘Namespace.ServiceName’ has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.
And for get more information please visite :

EJB JAX-WS Web Service authentication and authorization

How can I authenticate with HTTP Basic, via the application server domain/secure realm, using a Session Bean published as a #WebService?
In a Web project one could use web.xml to map Roles to Groups, but I have no idea how to do it in a EJB-JAR project. I don't think it can be done with ejb-jar.xml.
Sample code, which works fine without the roles annotations:
#Stateless
#WebService(portName="RestrictedServicePort")
#DeclareRoles(value = "Administrators")
public class RestrictedServiceBean {
#RolesAllowed(value = "Administrators")
public String restrictedOperation() {
return "Secret information";
}
}
Error:
<faultstring>[EJB:010160]Security Violation: User: '<anonymous>' has insufficient permission to access EJB: type=<ejb>
Basic Credentials Header:
Authorization: Basic d2VibG9naWM6d2VsY29tZTE=
I suspect it must be done via vendor-specific configuration. I am using WebLogic 10.3.6, Java EE 5 / EJB 3.0.
Basic Auth via Policy
From the v10 docs:
A Web service can have zero or more WS-Policy files associated with
it. WS-Policy files follow the guidelines of the WS-Policy
specification. WebLogic Server uses WS-Policy files to specify the
details of the message-level security (digital signatures and
encryption) and reliable messaging capabilities of a Web service. You
can attach a WS-Policy file to a Web service endpoint, which means
that the policy assertions apply to all the operations of a Web
service endpoint. You can also attach a WS-Policy file to an
operation, which means that the policy assertions apply only to the
specific operation. In addition, you can attach a WS-Policy file to
the inbound or outbound SOAP message, or both.
It would appear you can attach a basic auth policy to your service:
<sp:TransportToken>
<wsp:Policy>
<sp:HttpBasicAuthentication/>
</wsp:Policy>
</sp:TransportToken>
You can apply this custom policy via the administrative console via the steps outlined here or you can consider referencing one of the Oracle-preconfigured policies.
Mapping Roles to Groups
The WebLogic (v12) documentation mentions the following when discussing usage of #RolesAllowed in an EJB:
You can also use the annotation to explicitly declare roles that are implicitly declared if you use the #RolesAllowed annotation on the class or a method of the class.
You create security roles in WebLogic Server using the Administration Console. For details, see "Manage Security Roles" in the Oracle WebLogic Server Administration Console Help.
The Manage Security Roles section continues on to discuss scoped roles.
You can then create a scoped role for a specific EJB that contains highly sensitive business logic. When you create a policy for the EJB, you can specify that only the scoped role can access the EJB.
More information on managing scoped roles is here.
Solved adding the role mapping as it is done in any web module, but using the proprietary weblogic-ejb-jar.xml, as follows:
<wls:security-role-assignment>
<wls:role-name>Administrators</wls:role-name>
<wls:principal-name>myweblogicgroup</wls:principal-name>
</wls:security-role-assignment>
The "myweblogicgroup" is the group created in the WebLogic security realm for which the system user used to authenticated to the web service is associated.
This link helped me.

HTTP Error 401.1 when using WinHttp.WinHttpRequest.5.1 in classic ASP site

General information
Operating System: Windows Server 2003 R2 Service pack 2
Webserver: IIS 6
NTAuthenticationProviders: NTLM only
Webapplication: Classic ASP
Browsers used: IE7, IE8, IE9
There’s a Classic ASP web application called knowledgebase, within an IIS website called eblcplaza like so: eblcplaza/knowledgebase/.
eblcplaza has anonymous access AND Integrated Windows Authentication enabled.
knowledgebase has anonymous access disabled and Integrated Windows Authentication enabled
knowledgebase is a Classic ASP application has its own Application pool which runs under the predefined Application pool identity “Network service”
When I’m logged in with my NT account I can access any page I want just fine. The problem is with the WinHttp.WinHttpRequest.5.1 component. It’s used in some parts of knowledgebase to do a server side request to retrieve content from some .asp scripts which reside within the web application.
The problem started when Anonymous access was turned off on knowledgebase . Note, turning it back on is not an option.
Example of a request using WinHttpRequest:
set WinHTTPRequest = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
WinHTTPRequest.SetTimeouts 20000, 20000, 20000, 20000
call WinHTTPRequest.Open("POST", someUrlToAspScript, false)
WinHTTPRequest.SetAutoLogonPolicy 0
WinHTTPRequest.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
WinHTTPRequest.Send strQueryString
Response.Write(WinHTTPRequest.ResponseText)
With SetAutoLoginPolicy set to 0, I get the following error message on the pages where WinHttpRequest is used:
You do not have permission to view this directory or page using the credentials that you supplied.
HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)
With SetAutoLoginPolicy set to 2 (Do not automatically send user credentials according to MSDN), I get the following error message on the pages where WinHttpRequest is used:
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.
HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
I know for a fact that my NT user account has the proper rights to access those .asp scripts and so does the Network Service account.
I tried figuring out what could be the problem for several days know, tried setting the NTAuthenticationProviders to only NTLM and both Negotiate and NTLM amongst other things, but nothing worked so far.
Please help me out, It’s starting to drive me crazy.
Regards,
Bart
I guess the pages in knowledgebase are accessed with the anonymous account where you start from at eblcplaza. Try to enable NTLM only on the page in eblcplaza where you use the request, you can do that on that file only. Like that your credentials get passed to knowledgebase. On both pages log the Session("username") variable.
First of all let's clear up what it is you asking the server to do. It will have demanded your credentials from the client with which it is now impersonating you for security purposes. The WinHTTP request it is making to a service (WinHTTP doesn't know that its the exact same application) that now demands credentials. What you want this impersonating thread to do is use your creds to authenticate against an "external" service.
I suspect that what is happening here is that the server is not cleared to re-use your credentials in this way. If I recall correctly (which may not be that certain) a server needs to be granted the right to delegate in order to do that. It may also be possible to allow this if Kerberos is used instead of NTLM to perform windows integrated security.
However all that may be academic. You should understand that an app making a http request to itself has the potential to hang when under load in a way that would require a recycle to release.
Consider this alternative. Given that ServicePage.asp is a page used both directly by the browser and by an internal ClientPage.asp do the following.
Rip out the service code from ServicePage.asp and place in a VBScript class in a new ServiceInclude.asp. Now add the this ServiceInclude.asp as an include file in ServicePage.asp where ServicePage.asp only contains the plumbing necessary to instance the class and use it to generate its output.
Modify ClientPage.asp so that instead of attempting WinHttp to ServicePage.asp it simply includes the ServiceInclude.asp, instances the contained class and uses the class to provide the service required.

Passing windows credentials through web application, to WCF [duplicate]

i have some code that tries impersonate the callers windows security settings and then connect to another WCF service on a different machine
WindowsIdentity callerWindowsIdentity = ServiceSecurityContext.Current.WindowsIdentity;
using (callerWindowsIdentity.Impersonate())
{
NetTcpBinding binding = new NetTcpBinding();
binding.Security.Mode = SecurityMode.Message;
binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
EndpointAddress endpoint = new EndpointAddress(new Uri("net.tcp://serverName:9990/TestService1"));
ChannelFactory<WCFTest.ConsoleHost.IService1> channel = new ChannelFactory<WCFTest.ConsoleHost.IService1>(binding, endpoint);
WCFTest.ConsoleHost.IService1 service = channel.CreateChannel();
return service.PrintMessage(msg);
}
But I get the error:
"the caller was not authenticated by the service"
System.ServiceModel .... The request for security token could not be satisfied because authentication failed ...
The credentials I am trying to impersonate are valide windows credential for the box the service is on.
Any ideas why?
In order to support your scenario, you need to have an understanding of how Protocol Transition and Constrained Delegation work. You will need to configure both Active Directory and your WCF service endpoint(s) to support this. Note the use of the Service Principal Name (SPN). Take a look at the following link and see if they help you. The article has a sample to demonstrate the complete end-to-end configuration required to make this work.
How To: Impersonate the Original Caller in WCF Calling from a Web Application
Agree with marc_s this is the double-hop problem.
You need to get the windows authentication all the way through, therefore:
The request must be made in the context of a windows users
IIS must be configured to use windows authentication
Web.config must be set up for windows authentication with impersonate = true
The user that your application pool is running as, must be allowed to impersonate a user. This is the usual place where the double-hop problem occurs.
There is a right called "Impersonate a client after authentication"
http://blogs.technet.com/askperf/archive/2007/10/16/wmi-troubleshooting-impersonation-rights.aspx
Impersonation from you service to the next is a tricky issue, known as "double-hop" issue.
I don't have a final answer for that (I typically avoid it by using an explicit service account for the service that needs to call another service).
BUT: you should definitely check out the WCF Security Guidance on CodePlex and search for "Impersonation" - there are quite a few articles there that explain all the ins and outs of impersonating an original caller and why it's tricky.
Marc
If you are sure you have the credentials right on both hops, the next thing that could be causing the issue is the lack of the EndpointDnsIdentity being set on the endpoint.
DnsEndpointIdentity identity = new DnsEndpointIdentity("localhost"); // localhost is default. Change if your service uses a different value in the service's config.
Uri uri = new Uri("net.tcp://serverName:9990/TestService1");
endpoint = new EndpointAddress(uri, identity, new AddressHeaderCollection());

Resources