I need to propagate the Windows Identity of the current user across two service calls.
Service A (which runs under integrated authentication) calls Service B (which also runs under integrated authentication). I need to identify the user identity which was used to call Service A in Service B's code.
I know this is possible using delegation, by impersonating the User in Service A code and then call Service B from the impersonated code.
However, I only want to flow the identity and not impersonate the user. Is this possible without impersonation?
get the authenticated user using ServiceSecurityontext.Current.PrimaryIdentity.Name
Add this as either a header or a field in the downstream service request
I think you are looking for the impersonation level called "Identity". See this article for a description of different impersonation levels in WCF.
Related
i have a asp.net web app in which i take system logon name and grant him access if the user is a member of a particular AD group(PrimeMembers)
Now we have moved the authentication code to a WCF Service(IsPrimeMember), and we got another WCF Service(GetProfiles) which calls IsPrimeMember before providing data
Now the question, If i would have called the IsPrimeMember service in my asp.net app I can safely get Logon ID from HttpContext.Current.User.Identity.Name.ToString and would not be tampered.
But when i provide the service via URL and open to a group of memmbers members may try to get access by trying different combinations of logon ID's as querystring.
One thing is we can provide some Key(like Private Key) as ask them to pass along with URL.
any other thoughts how this can be achieved
After couples of WCF tutorials, I could develop a WCF client/Server application, both service and client applications are Windows Forms Application. I can call service using each client by specifying UserName and password. My WCF service applications also shows all the connected clients with their username as well. But, When multiple clients send a request to service then I'm not being able to identity which user has called the method. This is important as my application tend to have its own session for each client processing, just as any regular ASP.NET application has. Each user have their own Identity and its own Application Domain.
Moreover, I want my service to send messages back to client, so I have implemented callback contract. In addition, I'm using netTcpBinding as my applications need to run on my intranet.
How can I implement this scenario in WCF client/server application ?
Any help please ??
Thanks
Thanks for your previous reply. Its really helpful to me.
Now, What If I want to use custom authentication using username and password.
Lets assume that I have 50 clients with valid username and password. How can I get an identity of a client (out of those 50) whose is invoking a service method at a particular point of time ?
Thanks
In your server side code, you should be able to retrieve the caller's identity from the security context - something like:
if(ServiceSecurityContext.Current != null &&
ServiceSecurityContext.Current.PrimaryIdentity != null)
{
string userName = ServiceSecurityContext.Current.PrimaryIdentity.Name;
}
If you're calling a service with Windows authentication (which might also work for you - if you're on a corporate LAN, as it would seem) - you should be able to access the security context's .WindowsIdentity instead (this will be null for any other authencation mechanism).
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.
I am working with WCF Webhttp services. I have created a bunch of services and all that remains is to put in user authentication...
Questions
Keeping with the rest architecture style, should I authenticate each service call against the user db.
If so, I should just do authentication by supplying the credentials and password each time the service is called and make it secure with SSL. Basically, each webget/webinvoke function should contain the user credentials as parameters and I authenticate each call. Is this right? This seems rather inefficient.
Using session key somehow seems wrong but any pointers as to how to use Session in WCF Webhttp?
I am not working with ASP .net membership (will be looking into it soon) since I was working with Mysql and have my own registration/user database created. Should I be looking at that? Can I use a wcf authentication service along with wcf webhttp services?
Any literature on handling authentication in WCF webhttp services would be greatly helpful.
Many thanks
You can check Chapter 8 of RESTful .NET book (Amazon, Google books)
You will authenticate only the first call from the user, any subsequent calls will use the context of the authenticated user. There are several options how you can use SSL(TLS), like always or just when you send username/password.
I am not sure where exactly and how you store the authentication token (like in Session or similar type).
You don't need to use ASP.NET membership provider, in fact you may not use any membership provider at all, just use other authentication models. Usually, there will be only one authentication model per service, like you get the credentials, check them against persisted storage, if valid you set the security token and that token is used for all the next calls for a limited amount of time.
I like to use wcf (windows communication foundation) with windows authentication.
Do I need Active directory for this purpose?
How the server knows about the identity of the client?
If someone can found out the pass of the client that is using the wcf services, can he create the same user name on different computer and use the password to access the wcf services ?
Yes, if you want to use Windows authentication, you need Active Directory as the source where the user gets validated.
The way this happens is by means of a user "token" - when your client logs into his PC with his Windows credentials, the login process will check with AD whether the user is legit and issue a "token". This token is then used in calls to a WCF service to determine who it is that is calling the service.