Is there any solution out there for utilizing SqlMembershipProvider from a different server?

Motivation: The security zoning policy at our company doesn't allow any more to directly connect to the database from web servers. We have a legacy ASP.NET classic website with SqlMembershipProvider and corresponding connection string in it's web.config - which is against the security policy hence need rework - with minimum effort as usual.

My thoughts so far: a straightforward solution would be to create a web service on the app server which would use SqlMembershipProvider under the hood and expose the necessary methods. And this would be consumed on the web server by a proxy class that implements MembershipProvider. However I don't want to reinvent the hot water - especially if it's an old technology - so if any better idea or an off-the-shelf solution is already there please advise. The membership database is shared among multiple apps hence prefer to keep.

CodePudding user response：

this in theory would be possible, but you would have to inherit the sql provider classes, (role and me membership and thus write your own provider. That "other" server will of course have some connection to the sql security provider database, so that other server would in theory be breaking the VERY SAME rule you attempting to avoid. So, how is that other server going to work when it breaks the very same thing you not allowing in this application? I mean, you could remove the connection string from the web.config, and place it say into a static class of some type. I mean if the ONLY reason and goal here is to remove the connection string information from the web.config, then it sure seems like a tall order to THEN re-write the security providers.

So, you certainly could cook up your own provider. The number of methods of each of the 3 providers you need is quite large, but out of those events, you only need a few. However, not only would you need to inherit the 3 classes (Visual studio can and will write out the code stubs automatic for you), but you ALSO have to add and write all those methods on the OTHER server that you plan to hit.

so, you would have a boatload of events and web methods to write on that other server.

I have written my own providers - and my reason was I did not want to use the "standard" set of tables generated by the built in provider, but wanted to use some existing tables from an existing applcation. However, it was still worth the efforts, since by using the correct and standard security providers, then ALL OF the built in IIS secuirty settings such as securing pages in web.config for each folder would then work. (which thus is MUCH better then attempting to roll your own security).

So, your goal and idea is not all that bad, but it would require code on both web sites for this to work.

When you inherent the security role provider classe, you get this:

Now, out of above? I did not bother to implement ALL OF the methods. Only a few.

(this would meant that I can't necessary use the IIS tools to setup and manage roles, but they do work just fine in terms of setting up say a folder and those pages being limited to a given role.

From above, I only really needed these:

FindusersInRole

GetAllRoles

GetRolesForUser

GetUsersInRole

IsUserInRole.

The rest of them? I just left them blank, say like this:

So, I did not bother to re-create all methods - I in fact left most empty.

Same goes for the "membership provider".

However, this all sure seems like a lot of work to "just" get the connection string out of web.config.

So, why not just move the connection string out - put it some place else then? So, you might still want to inherit the existing role and membership provider classes, and thus have a code based means setup for the connection string.

But, to setup web service calls to another site? Gee, you would have to make a web method on that other server for each of the role class methods, and also the membership provider class. I suppose if you code web methods all day long, done lots of this before? Then it would not be too much work.

seems to me, it would be far easier to just move the connection settings out of web config, and along with inheriting role and membership providers, then you could override (provide your own connection string outside of web config).

However, no, I don't know of a pre made solution for this.

As noted, out of the what, about 30 methods, I only did use about 4-5 of them, and I did not bother coding out all methods. So, for example, I did not re-create "add user to roles" since it was easier to just edit the role table directly, and add the 3-5 roles I needed, and thus not changed that for years now.