Ok, Im really going to show my stupidity regarding the ASP.NET security model here but here goes.
I have a WCF web service and I have managed to hack my way around to having it pipe through my custom membership provider.
My membership provider overrides "ValidateUser" in which I attempt to load a user object with data from our SQL server instance. All good so far, I retrieve the creds, load the users object and return true if I don't hit any bumps in the road.
At this point, I would usually stuff the user object (or id) into session or actually just some state bag that's accessible for the lifetime of the request. The problem that I am hitting is that HttpContext is null at this point, even though Im using ASP compatability attributes.
What other options do I have at hand?
Cheers, Chris.
EDIT:
Just to clarify what I want to do. I want to pass user credentials to be authenticated on the server, and once this has happened I would like to keep the the details of the authenticated user somewhere that I can access for the lifetime of the service request only. This would be the equiv of Http.Current.Items?
Is there any object that is instantiated per-request that I can access globally via a static property (i.e. in a similar way to HttpContext.Current)? I assumed that OperationContext was the this, but this is also null?
Can this really be such an uncommon problem? Send creds > retrieve user > stuff user somewhere for access throughout processing the request. Seems pretty common to me, what am I missing?
Cheers, Chris.
Basically, with WCF, the preferred best practice solution is to use per-call activation, e.g. each new request / call gets a new instance of the service class, and all the necessary steps like authentication and authorization are done for each request.
This may sound inefficient, but web apps, and in particular web services, ought to be totally stateless whenever possible. Putting stuff in a "state bag" just calls for problems further down the road - how do you know when to invalidate that cached copy of the credentials? What if the user exists your app but the cookie stays on his machine?
All in all, I would strongly suggest trying to get used to the idea of doing these step each and every time. Yes, it costs a little bit of processing time - but on the other hand, you can save yourself from a lot of grief in terms of state management in an inherently stateless environment - always a kludge, no matter how you look at it....
If you still insist on that kludge, you can turn on an ASP.NET "compabitility" mode for WCF which should give you access to HttpContext - but again: I would strongly recommend against it. The first and most obvious limitation is that this ASP.NET compatibility mode of course only works when hosting your WCF service in IIS - which I would again rather not do in production code myself.
To turn on the ASP.NET compatibility mode, use this setting in web.config:
<system.serviceModel>
<serviceHostingEnvironment
aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
and you need to decorate your service implementation (the class implementing the service contract) with a corresponding attribute:
[AspNetCompatibilityRequirements(RequirementsMode=
AspNetCompatibilityRequirementsMode.Allowed)]
class YourService : IYourService
The AspNetCompatibilityRequirementsMode can be NotAllowed, Allowed or Required.
For more information and a more thorough explanation, see Wenlong Dong's blog post on ASP.NET Compatibility Mode
Related
I'm wondering... why does Microsoft use this:
services.AddTransient<IEmailSender, AuthMessageSender>();
In their tutorials for sending e-mails in ASP.NET Core rather than:
services.AddSingleton<IEmailSender, AuthMessageSender>();
Isn't the service supposed to stay the same for the lifetime of the project?
What is the downside of this?
Thanks :)
The reason why they use Transient its because their example is based on Forgot Password.
Forgot password is something secundary it doesnt do part of the main app logic, so it is cheaper in terms of resources to create the service once you need it and after use, discard it. This is the reason they use Transient.
If its a singleton it will be always in memory once it is created and for the forgot passward case which is rare to happens, it is not worth it.
So bear with me, i am new at MVC and WCF. I already have a set of services (WCF) that exposes my BLL and I am trying to consume those from my MVC.net web application but i am unsure on how to perform security operations here.
These are my app requirements:
Be able to consume WCF services using different credentials for every user on the web application
My BLL (WCF) needs to know what consumer is calling it (right now I only have the MVC app but i am planning to add iOS and Andriod calls to it, so later on i will add REST services to the WCF endpoints) Is there any design pattern for this out there? (or should i just use the soap header to include the caller ID? should i use some sort of caller secret or something?)
I need a security mechanism like Tokens or something so I dont have to pass the username and password on every call of the service method (WCF)
What i have so far:
WCF uses a certificate and and with a custom username validator.
I have manually coded proxies using the contract interfaces instead of generated proxies: But I hate the fact that i have to validate username and password every time a call is made to a WCF service. How in heaven can i use Tokens here? like to know if a given token sent on the soap header is valid or not yet expired? i have searched a lot and no tutorial/code/example is clear enough for me to actually start coding that ;(
I am trying to cache the ChannelFactory but should I? i mean, i will need to cache a channer factory per logged in user per contract ;( is that ok? what can i do here?
Thanks in advance!
Should you cache the ChannelFactory per user per contract?
It depends. There are a couple of considerations. Instantiating a channel factory could take up to 70ms. If you are doing this repeatedly, you will see a noticeable performance hit if you are not caching the ChannelFactory and instantiating one (or more) each time a user makes a http request to your MVC app that results in controller actions calling web services. This would indicate that caching the channelFactory would be beneficial for speed.
On the other hand, depending on the number of users you have, if you are caching a lot of channel factories (in a static dictionary for example), you are going to start to use a non-trivial amount of memory - this may become an issue for you.
You have to decide if the cost of instantiating channel factories on the fly (and correctly closing / aborting them and their contained channels) is too high a price vs increasing memory utilisation in the application pool hosting your MVC app.
Either way, I strongly advise to profile your app before you deploy to production.
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.
I am migrating a web service to WCF so I can use binary encoding. I am now realizing that the session calls and application state calls are not recognized. WCF is supposed to be better then a web service so I am assuming that there is a better way to do things.
1) How do I maintain session and call a web service that uses session?
2) How do I replace the application object?
For those of you who are migrating a large project and cannot afford to be so ideological, I found a real answer here:
http://megakemp.wordpress.com/2008/11/27/migrating-aspnet-web-services-to-wcf/
In WCF, the best practice is not to have any state whenever possible, since your clients should be calling you with a "per-call" approach - each call from a client gets a new instance of your WCF service class, which is totally independent of anything else, ideally.
If you need to have persistent state, store it in a persistent store - typically a database.
WCF is also by default totally independent of ASP.NET and IIS, and thus cannot leverage the HttpContext, HttpSessionState and so forth objects - since it might be self-hosted in a console app which has no knowledge of IIS, HTTP context etc.
The question is: what exactly do you really use from those HttpSessionState and HttpApplicationState objects? Somehow, you need to abstract that away or solve it some other way, e.g. have the client send you that information (as a parameter on your web service method call, or as a header in the message), or have the client send you a "token" of sorts which allows you to retrieve the relevant info from e.g. a database table.
Chapter 4 in Juval Lowy's excellent Programming WCF Services (link) is all about Instance Management. There are sections on Per-Session services and Durable services, each of which might be what you're looking for.
However, Marc's point is very valid. There are a lot of cons to using session with WCF services, but it is possible. Lowy discusses a lot of this in some detail.
I'm looking for some input for a challenge that I'm currently facing.
I have built a custom WIF STS which I use to identify users who want to call some WCF services that my system offers. The WCF services use a custom authorization manager that determines whether or not the caller has the required claims to invoke a given service.
Now, I'm building a WPF app. on top of those WCF services. I'm using the MVVM pattern, such that the View Model invokes the protected WCF services (which implement the Model). The challenge that I'm facing is that I do not know whether or not the current user can succesfully invoke the web service methods without actually invoking them. Basically, what I want to achieve is to enable/disable certain parts of the UI based on the ability to succesfully invoke a method.
The best solution that I have come up with thus far is to create a service, which based on the same business logic as the custom authorization policy manager will be able to determine whether or not a user can invoke a given method. Now, the method would have to passed to this service as a string, or actually two strings, ServiceAddress and Method (Action), and based on that input, the service would be able to determine if the current user has the required claims to access the method. Obviously, for this to work, this service would itself have to require a issued token from the same STS, and with the same claims, in order to do its job.
Have any of you done something similar in the past, or do you have any good ideas on how to do this?
Thanks in advance,
Klaus
This depends a bit on what claims you're requiring in your services.
If your services require the same set of claims, I would recommend making a service that does nothing but checks the claims, and call that in advance. This would let you "pre-authorize" the user, in turn enabling/disabling the appropriate portions of the UI. When it comes time to call your actual services, the user can just call them at will, and you've already checked that it's safe.
If the services all require different sets of claims, and there is no easy way to verify that they will work in advance, I would just let the user call them, and handle this via normal exception handling. This is going to make life a bit trickier, though, since you'll have to let the user try (and fail) then disable.
Otherwise, you can do something like what you suggested - put in some form of catalog you can query for a specific user. In addition to just passing a address/method, it might be nicer to allow you to just pass an address, and retrieve the entire set of allowed (or disallowed, whichever is smaller) methods. This way you could reduce the round trips just for authentication.
An approach that I have taken is a class that does the inspection of a ClaimSet to guard the methods behind the service. I use attributes to decorate the methods with type, resource and right property values. Then the inspection class has a Demand method that throws an exception if the caller's ClaimSet does not contain a Claim with those property values. So before any method code executes, the claim inspection demand is called first. If the method is still executing after the demand, then the caller is good. There is also a bool function in the inspection class to answer the same question (does the caller have the appropriate claims) without throwing an exception.
I then package the inspection class so that it is deployed with clients and, as long as the client can also get the caller's ClaimSet (which I provide via a GetClaimSet method on the service) then it has everything it needs to make the same evaluations that the domain model is doing. I then use the bool method of the claim inspection class in the CanExecute method of ICommand properties in my view models to enable/disable controls and basically keep the user from getting authorization exceptions by not letting them do things that they don't have the claims for.
As far as how the client knows what claims are required for what methods, I guess I leave that up to the client developer to just know. In general on my projects this isn't a big problem because the methods have been very classic crud. So if the method is to add an Apple, then the claim required is intuitively going to be Type = Apple, Right = Add.
Not sure if this helps your situation but it has worked pretty well on some projects I have done.