In the GUI, we have a repeater control with a templated row for each provider. The reason is that we need to keep track of where the groups and roles came from, otherwise when the user click submit, how can we easily figure out where to do the update? So I think your approach would not work in our particular case.
We have instead added a static method "IEnumerable<MyProvider> MyProvider.GetProviders(Predicate<MyProvider> filter)" which gives the application all the flexibility needed. We also have decided to build our own Membership/Role providers for various reasons: 1. we needed to offer security providers (membership, roles, application permissions) in .NET CE, and System.Web on .NET CE has taken a bit of a diet... (part of the reasons behind my previous question about System.Security). System.Configuration is also nonexistent btw, as is the System.Security.Principal namespace, which is kind of a bummer. 2. we needed a database provider which is database agnostic and not tied to SQL Server 3. we needed more flexibility when parameterizing the ActiveDirectory provider (override default LDAP queries, scope, referral chasing, etc.) 4. we needed to associate application roles to security groups instead of users 5. we needed flexibility when identifying an AD object (use DN, RDN, GUID, SID, SAMAccountName, etc.), but always use the same unique identifier in DB store (GUID for now, but I would prefer SID if safe, investigating that...) 6. we needed more performance for ActiveDirectory (less properties retrieved, less memory used for large queries, ...) 7. we needed to merge the output of all configured and enabled providers, so we made static methods returning unique results 8. we did not see any real advantage to duplicate everything in Membership and Roles class. Making protected abstract/virtual xxxCore methods and wrapping those with public methods seems more appropriate. 9. we already had extended ProviderBase to greatly simplify the process of creating new providers, so we would prefer to use it 10.we felt the amount of work needed to fully implement a new Role/MembershipProvider was too high with some stuff we do not need (like number of users online). Throwing NotImplementException looks more like a patch than a real solution While the existing providers and tools are useful, in our case, they were lacking meat in certain areas. Sébastien > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Scott Guthrie > Sent: Thursday, November 30, 2006 1:02 AM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Multiple Membership Providers > > One approach you could take to combine multiple providers together > would be to build a new composite Membership/Role provider that in turn > manages and calls-through to a group of providers that it manages > internally (it can just create the providers programmatically and call > into them). This would allows you to have the app then just call > GetGroupsForUser and retrieve all groups from all the providers. > > We kept the providers in System.Web.Security as opposed to the more > general System.Security because some of the semantics are more server > specific as opposed to being totally app agnostic. More general > concepts that the providers use like Identity and the Principal objects > do live in System.Security though. > > In the next release of Windows Forms we are looking at add support for > Windows Forms clients to be able to connect and use the provider model > on the server to manage identity and role management for client > applications as well. > > This would allow an administrator to centrally manage roles/permissions > for Windows Forms apps (and even allow them to optionally use the new > IIS7 admin tool to manage them via a rich admin GUI - some screen shots > of this in action can be found here: > http://weblogs.asp.net/scottgu/archive/2006/09/07/IIS-7.0-RC1.aspx). > All of the Windows Forms apps configured to use this role/permissions > store within your enterprise would then be able to pick up and use the > data directly (all of the web-service plumbing to-do this would be > handled for you). > > Hope this helps, > > Scott > > -----Original Message----- > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Sébastien Lorion > Sent: Wednesday, November 29, 2006 8:49 AM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Multiple Membership Providers > > If you need a specific provider, Scott answer is right on. Sorry for > the confusion ... > > My answer was more appropriate if you need to select a group of > related providers. For example, we have a single DB store for role > management for a specific application, but membership information is > coming from different independent systems connecting to this > application. So for the administration of that application, we have a > central interface where you can assign role(s) to the groups obtained > from various providers. To get these providers, we loop and select > only those we need. > > I am actually completing the work on this interface, so I missed the > "obvious" answer. > > After working on this, two questions remain for me: > > - why there is no concept of "group" in the available provider base > classes? > > - why are the base providers and ActiveDirectory* in > System.Web.Security instead of System.Security? > > It would have been nice to have something like GetAllGroups(), > GetGroupsForUser(string username), GetRolesForGroup(string groupName), > etc. > > Sébastien > > On 11/29/06, Scott Guthrie <[EMAIL PROTECTED]> wrote: > > In a nutshell, you can control which provider is the "default" > provider by setting the "defaultProvider" property that is on the > <membership>, <roles>, <profile> elements in web.config. When you do > this, then calls to: > > > > Membership.ValidateUser(username, password) > > > > And other methods on the Membership class will go to the default > provider. You can programmatically call another provider by accessing > it via the "Providers" collection on the Membership/Roles API. For > example: > > > > > Membership.Providers["otherprovider"].ValidateUser(username,password) > > > > Note that the "otherprovider" name is determined by the <add/> > element in your web.config file (where you give each provider a name). > > > > Hope this helps, > > > > Scott > > > > -----Original Message----- > > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Sébastien Lorion > > Sent: Wednesday, November 29, 2006 6:06 AM > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > Subject: Re: [ADVANCED-DOTNET] Multiple Membership Providers > > > > You need to loop over System.Web.Security.Membership.Providers and > > somehow find the provider you want, e.g. by checking its type and/or > > some properties. > > > > Sébastien > > > > On 11/29/06, Angel Java Lopez <[EMAIL PROTECTED]> wrote: > > > Hi people! > > > > > > At MSDN article: > > > > > > Membership Providers > > > http://msdn2.microsoft.com/en-us/library/sx3h274z.aspx > > > > > > I read > > > > > > You can also configure multiple membership providers, which allows > you to select a membership provider at run time based on application > requirements. For example, for business reasons your membership > information might be in separate regional databases. By configuring > multiple membership providers that each interact with a different > regional database, you can direct membership calls to the appropriate > provider for different users. > > > > > > But I can't found any sample code or explanation on how to specify > the membership provider to use at runtime. > > > > > > Any info, welcome! > > > > > > Angel "Java" Lopez > > > http://www.ajlopez.com/en > > > http://ajlopez.wordpress.com/ > > > > > > =================================== > > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > http://discuss.develop.com > > > > =================================== > This list is hosted by DevelopMentor® http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor® http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
