I've implemented a custom ASP.net membership provider to deal with forms authentication. The custom provider uses a custom User object for authentication and authorization. I was wondering If I can pass this object to each WCF call without adding it to the parameters list?
Since you are already using a MembershipProvider you can utalize that on wcf as well so both are secured by the same mechanism.
See this post on msdn.
Windows Communication Foundation (WCF)
developers can take advantage of these
features for security purposes. When
integrated into an WCF application,
users must supply a user name/password
combination to the WCF client
application. To transfer the data to
the WCF service, use a binding that
supports user name/password
credentials, such as the WSHttpBinding
(in configuration, the wsHttpBinding
Element) and set the client credential
type to UserName. On the service, WCF
security authenticates the user based
on the user name and password, and
also assigns the role specified by the
ASP.NET role.
Another option would be to create a custom IAuthorizationPolicy that pulls off your user via
OperationContext.Current.IncomingMessageHeaders.GetHeader<T>
And than setup your principal like the following:
evaluationContext.Properties[Constants.EvaluationContextPrincipal] = principal;
Here is some more information on creating a custom IAuthroizationPolicy. With this method you could achieve what you want without passing your user to the method.
Just be warned if you go this route a crafty person could end up impersonating the user by simply suppling a bogus user in your header.
Using the asp.net membership provider for wcf would most likely get you what you are really after plus adding some security.
You definitely should not add this to the parameters each method.
I do not know about your custom user object but as far as WS* and most security standards concerned, your user object will have username and password.
The answer depends on the binding you use. BasicHttpBinding or BasicHttpContextBinding can use HTTP authentication schemes while WsHttpBinding can use custom Message security which you can provide user name and password.
BasicHttpContextBinding is especially good since it can work with ASP NET session.
Related
I have an MVC4 ASP.net financial application with a WCF service. The current scenario isn't secure enough and I need you help with that.
The current scenario:
The user login using a login form, and I send his login details using a JSON object containing the UserID and the Password to the WCF service:
http://example.com:22559/Login
This returns a JSON object with a true or false.
If it's true, I use the ASP function
FormsAuthentication.SetAuthCookie(loginModel.UserID, loginModel.RememberMe);
to set authorization cookies to use it later.
When the user adds a new Transaction I send a JSON object containing the transaction details without the password to:
http://example.com:22559/AddTransaction
I depend here that the MVC controller will not allow the user to access the transaction page if he isn't logged in.
The problem is anyone can now sneak-out and add a transaction without entering the password!, using the URL:
http://example.com:22559/AddTransaction
What I need to do now, is to make the WCF service itself secured, but I don't know how to do that without making the user enter his username and password each time he adds a new transaction!, so, what is the proper way to do that?
Thanks in advance.
MVC 4's controllers typically use MemberShipProvider for authentication and RoleProvider for authorization. So your WCF services may share the providers.
For authentication, you don't need to do anything in WCF codes. For authorization, it is handy to decorate respective operation implementation function (not interface) with PrincipalPermissionAttribute with the Role name defined. The rest will be done in config and by runtime.
For more details, just search "membershipprovider wcf", you will find a lot articles/tutorials in MSDN, CodeProject and StackOverflow.
Please be mindful that in MVC 5 if you will be moving to MVC5, Identity 2.0 is used by default, and MembershipProvider and RoleProvider will not be their by default. Nevertheless, your WCF codes should remain unchanged, and only some elements under ServiceModel will need to adapt the new custom authentication and authorization, and the client codes should remain the same as well, no config change needed.
I am relatively new to uisng ADFS (in ASP.NET) which is what my company wants to use and just have a few basic questions about that:
Am I correct there is no explicit "Authorize" call you can do like with ASP.NET Membership Providers? Unless you on a domain it presents you with a login screen and once you enter credentials it does validation and returns back a token with claims information.
Can you configure some forms to allow anonymous access like you can do with Forms Authentication?
Thanks.
Yes, you can setup pages in your app that don't require authentication. It works exactly like you'd do with Forms Auth.
On #1: in a claims based model, your app relies on an external system to authenticate users and receives evidence that the user is valid in the form of a token. You can completely automate this (using WIF and config files), or you can explicitly trigger the authentication process. In any case, your app won't be responsible for validating legitimate users anymore. It is a responsibility that it delegates to the STS (e.g. ADFS). That's why apps are called "relying parties".
I'd suggest you read the first couple chapters of the A Guide to Claims based Identity for a better understanding of the underlying principles.
Development Environment: Windows 7 Enterprise with
.NET 4.0 with Visual Studio 2010
Production Environment: Windows 2008 Server with IIS 7.0
I'm trying to figure out the best way to authenticate and authorize against a WCF service running on a separate machine in a separate security zone from the ASP .NET web application.
Users log in with a username and password against credentials we have stored in a database. We did not implement Membership Provider, but when the user's credentials pass mustard, we manually create a Forms Auth ticket with the user id.
I did roll my own Role Provider that implements RoleProvider. As a result, we have "standard" ASP .NET roles along with a forms auth ticket working on our ASP .NET web application.
What I need to do is somehow pass these credentials along to the WCF service that's sitting on another machine. Originally, I thought I might use the Windows Identity Foundation and create a custom Security Token Service (STS). Basically, if the user authenticates, then create a token and add in the claims based authorization along with user identity into the token and pass that along to the WCF service.
We are currently using a .NET Remoting service (.NET 1.1 timeframe) that does not authenticate or authorize at all.
That seems like it might be a bit of overkill as there might be a way to simply pass along the information I currently have with the user as when you create the Forms Auth ticket, I know the current IPrinciple is set with the IIdentity set with a "name" property set to the user id on the Thread.CurrentIdentity.
I'm pretty sure IsInRole("WhateverRole") would work correctly at this point too, but all of this is on the Web application side. Nothing gets passed to the .NET Remoting service.
Looking at these two classes:
AuthenticationService Class
ServiceAuthorization Class
I don't think they are what I want. Likewise, I've read through Michele Bustamante's Learning WCF, but I don't really see this particular scenario covered. When I read about Windows Authentication, I keep thinking that needs to be tied into some internal NTLM or Kerberos associated with the internal Windows security situation. None of our users are internal users. They're strictly external.
Now, I know that if the user gets a Forms Auth ticket, they essentially get a valid IPrinciple and the roles should be set, right?
If so, is there a way to pass this along to a WCF service setting on another machine? If I set the WCF clientCredentialType to windows and set the serviceAuthorization principlePermissionMode to "UseAspNetRoles", will these be passed along in the security context from the web application to the WCF service when I make the service call?
Nothing I can find is clear on how this might happen. Thanks.
I think what you want is this:
http://thoughtorientedarchitecture.blogspot.com/2009/10/flowing-aspnet-forms-authentication.html
This isn't super secure, since you're effectively creating your own man-in-the-middle attack, but it's probably secure enough for most needs.
Essentially this boils down to this:
Configure both servers with the same MachineKey
Grab the FormsAuthentication cookie from the user request
Attach the cookie to the outgoing WCF service call
???
Profit
I'm attempting to add a feature to an existing ASP.net web site that needs to pull the users calendar data from the Exchange Web Service. I know that this is possible, and have local tests running as a proof of concept, but I'm having some issues in implementing this in the context of an ASP website.
My intention is to override the default credentials by constructing an instance of the WebCredentials class using the current user of the ASP sites credentials and then using this to create an Exchange Service Binding.
Example
ExchangeService service = new ExchangeService(ExchnageVersion.2007);
service.AutoDetect(emailAddress);
service.Credentials = new WebCredentials(credentials);
Unfortunately, the WebCredentials object can only be constructed from either a set of strings containing username, password and domain, or by passing in an ICredentials object.
So, the question is, within a Forms authenticated web site, is there any way to obtain an ICredentials object for the currently authenticated user?
No forms authentication uses an bespoke encrypted cookie which is sent by the browser with every request. It let's ASP.NET know that the user is authenticated and who they are. It's not designed to work with external systems, and in fact it requires the machinekey on the server to be able to decrypt the details. Passing forms credentials to another server would be pointless.
This system is different to Windows auth which can use various authentication schemes such as basic, digest, NTLM, and Kerberos authentication to negotiate credentials as part of the HTTP protocol, and which can be understood by external systems on the same Exchange.
So to use ICredentials you either need to be using Windows authentication in your ASP.Net application, or have access to username/password so that you can use NetworkCrententials explicitly.
I'm writing an admin panel in ASP.NET for an existing set of web service calls. My goal is to use some of the existing login stuff (locking out pages if your not logged in) etc but using my login mechanism. This works by hitting an http post request with a username and password, if you're good you get a session id back, if not you get a 401. Here is the WCF for that:
[WebInvoke(UriTemplate = "/Login/", Method = "POST")]
public String Login(User user)
{
// If we are good return sessiond id
// Otherwise throw 401 etc
So to get this working in ASP.Net what is needed?
I think this:
Implement a user that overrides MembershipUser and has a session id in it.
Implement a membership provider that overrides MembershipProvider and does all the WCF calls etc.
In the Web.Config set up a custom membership provider.
Is this correct or am I missing something major?
Rather than do this yourself, you might want to take a look at the WCF Authentication Services.
Before you go down this route, be aware that the authentication services supports login and logout, but that is about it. The usual Membership methods such as CreateUser aren't available. If you need them, you'll need to create three projects:
A WCF Service Application with a single service called WCFMembershipService that wraps the core Membership Provider requirements, i.e. calling Membership.Provider.Method(). Configure the standard SQLMembershipProvider in the web.config, and
A custom membership provider to be used in the ASP.NET application that calls your WCF service from step 1, and
An ASP.NET Application with the custom membership provider configured
You will find that the Membership and Role providers are extremely easy, but the Profile provider is more challenging, because you cannot serialize the default properties that the provider requires, such as SettingsPropertyValueCollection.
In this case, you would need to convert the SettingsPropertyValueCollection into a serializable type first, and then reconstruct it at the other end. Probably a Dictionary<string, string>() would suffice.