I have a remote WCF service where I have implemented a custom authorization manager. As part of authorization I grab the windows identity of the client to perform some custom authorization.
The issue I am having is that the client process is running as 'UserA', but when it sends a request to the remote service on ServerX, the service sees 'UserB'.
I have established that this is happening as I have asked windows to cache client credentials for account 'UserB' when I have connected to ServerX at some stage in the past (e.g. via RDP). This is quite a common pattern as many devs have a 'user' account and an 'admin' account and frequently configure windows to cache credentials for their 'admin' accounts when connecting to remote machines.
I know how to manually clear items from the windows credential cache, but how can I prevent WCF from using the cache i.e. so that the client process identity is always used.
Related
I have an MVC application that will be running on an IIS 7.5 Server in an application pool running under a service account.
In my application I make a connection to a TFS server, this connection needs to be made by the service account.
My application enforces windows authentication, this is so I can gather usage data about which users use the application. I do this through a custom Action Filter in MVC to collect the username like this: HttpContext.User.Identity.Name
How is it possible for me to impersonate the service account, yet be able to keep the windows username of the original user? I can successfully connect to my TFS server if I use anonymous authentication, while running the application pool under the service account.
Let me know if you need more information.
i have a WCF service hosted in a managed windows service. This WCF service communicate with sharepoint through the client object model in order to create, delete and update the document. My WCF service use a netTCPBinding with message security and windows authentication.
I need to retrieve the identity of the caller to have the right user under the property 'create by' of the sharepoint document.
Without activating impersonation, the wcf run under an network application account (app_svc) and when i create a document, the 'create by' property have this value: 'app_svc'
When i use impersonation, the sharepoint give me a http 401 error. The WCF service and sharepoint are not on the same machine.
How i can do it? Note that i have no rights and no access on the Active Directory and the domain controller server.
Any Help would be appreciated.
i am not familiar with sharepoint. but when you're impersonating a client and try to forward the credentials to another machine, you have to ensure the following items:
the client gets authenticated through kerberos (set SPNs)
the sharepoint authenticates users though kerberos as well (set SPNs)
delegation to the target SPNs is activated on the technical domain account of the IIS application pool / service. If it is running under a local built-in account (network service, local system etc) delegation has to be activated on the computer account object in AD.
The whole scenario is also known as double-hopp scenario.
I cannot write a complete guide here. Best you google for impersonation, delegation and double-hop.
All the steps i mentioned require access to a AD domain controller.
I've got two MVC sites that use the same STS for authentication. I need to create a WCF service as part of one of the sites that allows the other site to retrieve data.
These sites could be on different machines accessible over the internet (although currently they're on the same machine) and the WCF service should only be able to be accessed from the client site. The authentication token used to log into the client site should be passed through to the WCF service.
I've been looking at the different WS-Security options available (Transport, Message etc) and it's not quite sinking in 100%, and I feel like I'd end up implementing something that seemed secure but wasn't actually secure due to a lack of understanding. Any help much appreciated.
Edit:
My first attempt was with transport layer security and setting the WCF service virtual directory with require SSL in IIS. However that left me with an error of:
"The remote certificate is invalid according to the validation procedure."
And I had no way of ensuring that a specific client was connecting to the service, only that a client had a certificate from a trusted CA. At least as far as I know. I'm probably missing something vital here.
The authentication token used to log into the client site should be
passed through to the WCF service.
In this case you should be requesting an "ActAs" token from the STS:
The WCF service should be configured as a Relying Party of the STS.
The MVC site should call back to the STS and request an ActAs token specific to the WCF service.
The MVC site uses the ActAs token to call the service.
The motivation for the complexity: Delegation, or traversing multilayer architectures
Since you mentioned WS standards:
Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)
Not knowing your STS its hard to say more, but Googling "ActAs token" will probably give you what you need.
I need to find a way to authenticate/authorize users in a WCF-service. I'm using an external authentication service which stores the credentials of the users.
Eg. "Bob uses our loginmethod, we send the credentials to the authentication service, the service lets us know if these credentials are correct."
If Bob sends another request, we need to know if Bob is already authenticated.
Now a session is being created on the client, but it needs to move to the server-side. We can not rely on clients for security.
Can this be solved by using security cookies or do any of you have a better suggestion?
EDIT! I can only use the authentication server and do not have access to it
The problem you are describing is a well-known one that had (at least) two standardized solutions.
Federation using WS-Trust
The first option is a SOAP based one that uses active federation based on WS-Trust. In this solution:
Your client provides credentials to the authentication service
If the credentials are valid, the authentication service returns a signed (and encrypted) token to the client. It is encrypted so that any information contained in the token remains confidential - even the client cannot read it. It is encrypted with a public key belonging to the your WCF service. It is signed with a private key belonging to the authentication service.
The client submits the signed/encrypted token to your WCF service. The service can decrypt it because it holds the private key for decryption. It can trust it because it is signed by the authentication service.
Based on the content of the decrypted token, the service can establish the client identity and make an authorization decision.
In this model, the usual terminology is:
Your authentication service the Security Token Service
Your WCF service is the Relying Party
your client is the Client
This sounds complex, but it is very well supported in .Net and WCF using Windows Identity Foundation. There are many samples available much of it (maybe all) can be done via WCF configuration rather than code.
This is well suited to scenarios where the clients are crypto-capable (like your .Net clients) and where good frameworks exist (like WIF). It is not so good for low spec clients such as browsers and some phones, or where you are not in control of the clients.
It is commonly used in enterprise scenarios, including enterprise-to-enterprise federation. It is used less often in internet scenarios.
the strengths of it are
It is standardised and therefore generally well supported by frameworks
It means that your WCF service never has to handle the client credentials (= more secure)
It makes it pretty easy to switch to different authentication services (because it is standardised). For example, on-premise AD and Windows Azure AD both support this, as do other independent identity services
An overview can be found here:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
And Google will show you lots more walkthroughs and examples.
Federation using OAUth 2
In this solution:
The client displays some UI provided by the authentication service (generally a web page)
The user enters their credentials in that UI and the authentication service authenticates and eventually returns a token to the client. The nature of the token is not standardised, nor is whether it is encrypted. Generally it will be at least signed.
The client submits the token with each request to the WCF service
The WCF service authenticates the token as in the previous solution
In the OAuth terminology:
Your authentication service is the Authorization Server
Your WCF service is the Resource Owner
Your client is the Client
Again, this sounds complex, but it is reasonably well supported in .Net. Probably not as well as the WS-Trust approach though at the moment. It is supported by Windows Azure AD and on the client side, using the Windows Azure Authentication Library. May other services use this approach - e.g. Facebook.
This works well where
Your client is low spec or not crypto-capable (e.g. a browser or some phones)
You do not control the client (e.g. a third party application is accessing your service)
It is very commonly used in internet application where you as an owner of the WCF service don't necessarily know the users or the clients. It is a less complete standard in some ways (e.g. it does not define exactly how the authentication happens) and as a result, it is less easy to switch to alternative authorisation servers.
The strengths of it are:
It is simpler and therefore has wider platform support
It is growing in popularity and therefore the library support is getting better all the time
The user never enters their credentials into your UI, only into the auth server, so it is more likely to be trusted (in internet scenarios)
It has a built in way of controlling the scope of the permissions granted to the client, and revoking those permissions, so again it is more trusted in an internet scenario
The official .Net support for this is in the Windows Azure AD Authentication library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
There are other, open source components too, such as DotNetOpenAuth
http://dotnetopenauth.net/
Which solution would be best for you depends mainly on the nature of your authentication service I would say. And on whether you are in an enterprise or internet scenario. If the auth. service could be easily adapted to be a WS-Trust Secure Token Service (STS), then that would be a good route. If adding some web UI to the auth. service is feasible, the OAuth might be better.
Or, if neither option is feasible, you could just borrow the patterns form one approach and use that without going for the full standard.
Good luck!
This is what I wish to achieve:
My ASP.NET web service is hosted on a server called //service. I want to control access to the web service by server and by application as well. What I mean here is if I have two ASP.NET web applications (app1 and app2) hosted on a server called //web1 and I only want //web1/app1 to be able to call the web service. I know that I can grant access to the IP address of //web1 but that would allow both //web1/app1 and //web1/app2 access to the web service.
I am thinking about using an SSL certificate as I don't want the web application to handle the login/password. on //service, I will grant access to the ip of //web1 and map a client certificate from //web1 to a windows account and this will allow only applications from //web1 to access. But then how do I further control the access to only //web1/app1?
You can use standard HTTP Authentication to control which applications have access to your web service.
Credentials are passed in the Authorization header with each request. Every web service client (i.e. //web1/app1) should have its own credentials, so if //web1/app2 tried to connect to the web service without providing recognized credentials, it would be denied access.
I recommend using SSL to encrypt all traffic, so that authentication information and other sensitive data is secure.
Here are a few articles that may be helpful:
HTTP Security and ASP.NET Web Services (see Authentication section)
Authentication in ASP.NET Web Services
Good luck!
Not really.
A certificate secures the transmission between the client and server domain. It doesn't really work to have multiple certificates for multiple subdirectories.
What you'd want to do is to create a login service that returns a token. You then use that token to manage the session on the server side and the client uses it along with every subsequent request to access and execute the available services. (can this token access this webservice? t/f)
You're going to have to give the client access to some sort of credentials. Whether that is a certificate exchange or a user/pass you're going to have to figure out who the client actually is.