What is the Microsoft Enterprise Application Blocks relationship to the ASP.NET provider model? (if any)
Enterprise library have a Security Application Block.
It exposes two interfaces that you can access in your code:
An Authorization Provider interface, which exposes the single method named Authorize that takes an instance of an IPrincipal object containing details of the user's identity and roles. Depending on the way that you configure the block, the authorization can take place either through Windows® Authorization Manager (AzMan) against Active Directory, an XML file, or a database; or by using custom rules that you define and are stored as XML in the application configuration file.
A Security Cache Provider interface, which exposes methods that allow you to save and retrieve a user's identity or security context as an IIdentity instance, IPrincipal instance, or ASP.NET Profile instance. Each cached identity or security context is identified by a token (by default a GUID, though you can create and use your own implementation of the IToken interface). The block stores this information in either a database or in Isolated Storage using the Caching Application Block. You can alternatively create a custom provider for the Caching Application Block and use it to cache the information in the location and using the techniques you implement in your provider.
Then you also can reference ASP.NET 2.0 Provider Model:
http://msdn.microsoft.com/zh-cn/library/aa479030.aspx
Related
At my workplace, we have many existing applications for which common WCF services have been written to expose user and role management functionality at the enterprise level. So, for example, to create a new user, our applications just call the Create method exposed by our UserService.
We are trying to build a new MVC5 web application which needs identity management features. I have found several examples of custom implementation of the ASP.NET identity framework which typically override the IUser, IUserManager, etc. I also found an implementation for MySQL database instead of SQL server. However, I am unable to figure out if it is possible to completely discard away the database part of the framework and hand over the persistence calls to our services but still use methods and facade provided by the framework for cookie management, Owin integration etc. Or enterprise schema, of course, does not match the default Identity framework database schema.
I looked at the Identity Sample from Microsoft that implements a user manager:
var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));
This custom user manager ApplicationUserManager needs a UserStore<ApplicationUser>, which needs a ApplicationDbContext. Is it possible to pass some service instance instead to the custom UserStore instead of a DbContext. Can the UserStore even work without a dependency on some database DbContext?
I created a DbContext connection using Entity Framework and have "DbContext" connection string in my web.config file.
Then, I tried to log in, and my website required me to have another "defaultConnection" string for creating user tables.
In this case, do I need to have two connections? Or should I have one connection by somehow combining the two?
Which is better performance-wise? I started building my project using Internet Application template.
By default for membership and roles, the ASP.net infrastructure uses the default membership and role providers that stores that membership and roles data in different database. Run your application and if you register for a user from login page you can see the database at location "App_Data" folder created. The database is different hence the connection string is different. You are using entity framework so there are 2 ways to go from here.
1) Change the connection string and use the same default asp.net membership and role providers to store data in the database that your entity framework configuration is using. By this I mean the default membership and role providers use the database that you EF configuration points to.
2) Use EF to manage the membership and roles data. So the users and groups would be entities manages by the DBcontext as other entities.
I have recently implemented the second approach. The ASP.net membership provides hooks (extensibility) to implement your own providers and register them in the web.config file. Then create the User and Role entity and include them in DBContext. Of-course before registering the providers you need to implement them first by deriving from MembershipProvider and RoleProvider abstract classes. These classes are in `System.Web.Security' namespace.
You can follow this project for more details http://codefirstmembership.codeplex.com/
I believe the connections to separate database will not have any impact on the performance. As in the web model even if you use same database for incoming requests we have to make connections to database separately and the incoming requests can come concurrent. In fact keeping the database separate will take to database load to another server. But now you have 2 servers to back up and maintain. This will not be maintainable unless you want your membership data to be separate for some reasons like it is shared by other applications also.
I would suggest combining the two, since at some point you will probably want foreign key's from various tables to the Users table.
I would have one connection in the web.config, "DefaultConnection".
Then when you initialize your DbContext, use the DbContext(string) overload to use the DefaultConnection, like so: var context = new YourDbContext("DefaultConnection");
That way your data and Users/Roles tables live together, happily ever after.
What are the authentication options for having a ASP.NET web application communicating with a WCF service?
The scenario:
User enters their username and password in an ASP.NET form.
ASP.NET needs to pass this to WCF to authenticate the user.
If authenticated, the user can perform actions on the website. Each action would require sending data to different WCF operations. WCF needs to know who the user is on each call.
The easiest solution would be to store the username/password in the ASP.NET session state. However, this is insecure because the password is stored in memory on the server.
I would rather not use a certificate to authenticate the ASP.NET "client" to the service because there's a possibility that this WCF could be consumed by another client in addition to ASP.NET.
The best suggestion I've seen so far is to use Windows Identity Foundation (WIF). It appears that this requires an STS. According to MSDN, Microsoft does not seem to recommend setting up an STS through Visual Studio. There's no guarantee that an STS would be available in the deployment environment as some environments may use Active Directory and other environments may have a custom user store. Is it possible to setup a custom STS to authenticate against a custom user store? I'm having trouble finding documentation on doing this.
Are there any other options besides using WIF? What about a custom WCF authentication service that returns a token that can be used for authenticating against a primary WCF service?
The standard way of doing this is by using WIF with Microsoft's STS viz. Active Directory Federation Services v2.0 (ADFS).
There are a number of custom STS available e.g. Identity Server. This use a SQL DB as an attribute store. It's open source so could be adapted to whatever you require.
You can create your own custom attribute store: AD FS 2.0 Attribute Store Overview.
TechNet WIF / WCF: WIF and WCF.
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.
This seems to be a simple question, but I cannot find the answer after much searching.
I have an application that uses the ASP.NET security system. The membership uses a System.Web.ClientServices.Providers.ClientFormsAuthenticationMembershipProvider type for the provider, and the roles, similarly, uses the System.Web.ClientServices.Providers.ClientRoleProvider type. Obviously, this application does NOT make a direct connection to the ASP.NET security DB, but uses these proxy classes when connecting to the configured serviceUri to get the security data.
What is the data type I should use for the provider of the profile information, using the same client services proxy method?