I have a website that uses ASP .Net membership and roles using the SqlMembershipProvider and SqlRoleProvider. Right now I am only using this for a small section of the site that only 2 people have access to. The site may expand in the near future and the number of users could grow into the thousands.
My question is, is there any kind of open source administration tool for managing users or am I stuck building my own? I can't really use the ASP .Net Web Application Administration Tool because, as far as I know, it is only accessible from Visual Studio. User administration would be handled by our help desk and would need to handle all of the things that the stored procedures in the SQL server provide such as adding users on the customer's behalf, resetting passwords, unlocking users, etc.
I just can't believe that an administration front-end has not been developed to handle these sorts of things and provide more functionality than the ASP .Net Configuration page provides.
Take a look at MyWSAT on CodePlex.
http://mywsat.codeplex.com/
MyWSAT aka ASP.NET WSAT is a WebForms based Website Starter Kit for the ASP.NET Membership Provider with Forms Authentication. It provides you with all the security features required for a site out of the box so you start focusing on building your pages. It allows you to manage membership users online once your site is deployed. It features complete administrative back-end functionality and designed to manage users, as well as admin pages for users to manage their own user data.
Related
I have a LightSwitch customer-order management application. The customers can login and only view their orders. I'm trying to create a similar web app but not sure what route to take - ASP.net...etc. since not all my clients have Silverlight installed. If I did this in ASP.NET with Visual Web Developer, how would I go about the authentication based on the customer record in the db? It wasn't as big of a deal in LightSwitch.
There is an article on Codeproject about sharing the authentication between a .NET app and LightSwitch. Basically it comes down to 2 things in the web.config; MachineKey, and Forms Cookie. These have to be the same in all web.config files, and it automatically works.
http://www.codeproject.com/KB/silverlight/DNNThingsForSale.aspx
Also, Team Foundation Server has a web front end, and it exactly represents what is in the application.... Team Foundation Server uses the exact same way of describing the UI as LightSwitch ... so you might find something there.
We have many custom built web applications (both external & internal) written in Classic ASP and ASP.NET 2.0 technologies. Internal users can upload files to these websites, which can then be viewed by External Users. In some cases, external users can upload documents as well.
Screenshot #1 gives a brief idea about the existing architecture.
Internal users upload documents to custom web applications. These documents are stored in a folder structure defined under the web application.
Meta data and user permissions like who can access the documents are stored in SQL Server database.
The same set of documents that are being uploaded to custom web applications also exist in SharePoint. However, the custom web applications are unaware of SharePoint. So, users have to download them from SharePoint and then Upload it to the custom web applications. We are currently using SharePoint 2010.
External users can also upload documents to the custom web applications. The meta data and user permissions of the document are saved into database based on the user who is uploading the document.
Screenshot #1:
Screenshot #2 shows the architecture that I am trying to achieve. I have done very little SharePoint development. Mostly, I have used the SharePoint web services to retrieve some list content but nothing more than that. Our future Custom Web Applications might be written using ASP.NET MVC. Please find the questions after the screenshot.
Screenshot #2:
Here are my questions:
I would like to have internal users continue to upload and maintain their documents in SharePoint. User security model is already defined in the SQL Server database. This security permissions should be available in the SharePoint document properties so users can choose who can view the document from the custom web applications. How can I achieve this? Should I have to copy the SQL Server user permissions info to SharePoint?
I believe that SharePoint Web Services or Business Connectivity Services (BCS) can help in retrieving the document and its related info from SharePoint. Which one of these would better suit this scenario?
Custom web app should display only the committed versions of the documents. If a user has checked out a document in SharePoint to make any changes, that checked out version of the document should not be visible to External users. Is that possible?
Has anyone tried this approach? Are there any pitfalls with this model? Are there any performance concerns with this design?
Will this design be of any hindrance if I rewrite our existing applications using ASP.NET MVC?
Is it possible to make use of SharePoint search feature within the custom web application (ASP.NET Web Forms / ASP.NET MVC)? In other words, can I send search criteria from custom web app and have SharePoint do the search and return the results back to custom web app?
I really appreciate your inputs.
Thanks in advance.
Question 1
Hard to say without having more details. So I'm going to assume that you currently use Active Directory for your authentication store. So this means that your SQL Server defines a list of roles and then has assigned memberships to these roles. I'm going to assume that your assigned membership is to AD users or groups. If this is true then I think your on the right path to push your permissions from SQL Server into SharePoint. SharePoint's API will accommodate what you need to do, however SharePoint has no built into mechanism for syncing your permission changes so that means you end up writing a whole lot of plumbing code. I would recommend that you research products that can handle the synchronization for you. Microsoft MIIS (I believe it is called Forefront Identity Management now) offer a set of architecture patterns that you should investigate.
Question 2
SharePoint Web Services or the SharePoint Client Access Services should work fine. I would highly recommend that use a proxy pattern to isolate your application from SharePoint calls (so you can isolate your application from SharePoint upgrades and potential content management server changes).
Question 3
Yes, that is possible. If you are using the publishing features of SharePoint Server (NOT SharePoint Foundation) you will have an easy way of identifying the current published version. Otherwise the service account you query with should be setup so it can only read published versions then SharePoint will automatically trim your query.
Question 4
I have not personally tried this design, but I really like the concept of creating a content management domain and then putting an abstract service layer on top of it. Will you have scale problems, depends on how you configure SharePoint and your applications. You can do it right or wrong. An depth answer between the two cannot be covered here. My one piece of advice is to make sure you plan for caching in your service interfaces (cache, cache, cache).
Question 5
Not if you implement it as a Service Layer. You would just use a repository pattern to call the service and return back entities for your model.
Question 6
Yes, Search is exposed via an API so it can be wrapped in a service layer too.
Good luck and feel free to contact me directly for more in depth discussion.
during web site design stage or when web site is running on production server?
If it's used then it's during design stage to make some settings, create (test) users and roles and mix these two together.
Personally I don't really use it during development for customers as these applications mostly have to integrate with a legacy users database or something else like NAM. For these I simply create custom membership and role providers, plug them in, works.
If you are building an asp.net site from scratch its a very useful tool to expedite your development process.
It can create an authentication system for you that ties directly into the login control available in visual studio.
I find it particularly useful for creating and configuring the .NET Roles and Membership tables.
I need to implement a SSO between a custom Asp.Net application and a SharePoint site. The asp .net Application has custom authentication and the sharepoint has windows authentication. I have already read about using forms authentication in both applications but i can not use forms authentication in Sharepoint.
Is this possible? Any tips and tricks?
Zorro,
Sharing a Forms Based Authentication (FBA) authorization cookie would be one of the cheaper and easier routes to investigate/implement, but you've indicated that FBA isn't an option for you. That said ...
... without knowing more about the custom authentication mechanism you have in place on your ASP.NET application, it's very difficult to offer a good suggestion. CptSkippy's question (regarding reconciliation) is a good one, as that becomes the basis for what's feasible and what isn't. If your app and site don't share a common user base, then SSO becomes a real challenge.
I don't know how feasible it is for you and your situation, but Microsoft's ISA 2006 server does an admirable job when used in an SSO role. It supports a wide variety of publishing and authentication mechanisms, and it plays quite nicely with SharePoint leveraging both NTLM and Kerberos authentication:
http://technet.microsoft.com/en-us/library/bb794722.aspx
The big question, again, is your custom ASP.NET application. If you've got some flexibility there, ISA may be a option.
For what it's worth!
Have you checked Microsoft Single Sign-On Service?
I'm not very experienced at using ASP.NET, but I've used built in membership providers for simple WebForms application, and I found them PITA when trying to extend the way they work (add/remove few fields and redo controls accordingly).
Now I'm preparing for MVC (ASP.NET MVC or Monorail based) project, and I'm thinking - is there a better way to handle users? Have them log in/log out, keep certain parts of the site available to certain users (like logged in users, or something similar to "share this with friends" feature of many social networking sites, where you can designate users that have access to certain things.
How best to acheave this in the way that will scale well?
I guess, I wasn't clear on that. To rephrase my question:
Would you use standard ASP.NET membership provider for a web-facing app, or something else (what)?
The Membership Provider in ASP.NET is very handy and extensible. It's simple to use the "off the shelf" features like Active Directory, SQL Server, and OpenLDAP. The main advantage is the ability to not reinvent the wheel. If your needs are more nuanced than that you can build your own provider by extending overriding the methods that the ASP.NET controls use.
I am building my own Custom Membership Provider for an e-commerce website. Below are some resources for more information on Membership Providers. I asked myself the same questions when I start that project.
These resources were useful to me for my decision:
Writing a Custom Membership Provider - DevX
How do I create a Customer Membership Provider - ASP.NET, Microsoft
Implementing a Membership Provider - MSDN
Examining ASP.NET 2.0's Membership, Roles, and Profile - 4GuysFromRolla
Create Custom Membership Provider for ASP.NET Website Security - David Hayden
Setting up a Custom Membership Provider - Channel 9
I personally don't think there is a need to use something other than the builtin stuff unless you either want to abuse yourself or your needs are impossible to satisfy by the builtin functionality.
Have you considered using ActiveDirectory for this? Or, perhaps, OpenLDAP? You can manage each user's groups, permissions, 'authority', and so on.
keep certain parts of the site available to certain users (like logged
in users, or something similar to "share this with friends" feature of
many social networking sites
I guess you must custom code your thing.
I also do not like the asp.net Membership and custom code my membership needs...
A nice membership provider is a really missing thing in asp.net side...
It depends.
If it's an internal application, Active Directory or OpenLDAP might be the way to go.
If it's a public application, I suggest to look at aspnet_regsql. You will be able to setup a database with Authentication in no time.