I am building a desktop application that needs to update current user's status frequently. This status will be available as RSS feed.
In order to do this, I think I can create a asp.net folder and secure it using form authentication. When the desktop application written as winform in c# needs to update status, it can set WebRequest.Credentials and upload data.
Is there any better way of doing this?
Thanks
Forms Authentication might be a little 'overkill' for what it sounds like you're trying to do. Consider writing a simple .NET web service, and using SoapAuthentication or even passing in some credentials (or an authentication token that your server recognises) as parameters to the web method. It depends on how important security is, and what kind of traffic you think your desktop application will generate.
It's difficult to be more specific without more details! :)
Related
I have an old .net based system with its own, custom, database of users.
Can I implement IdentityServer4, such that all login and related requests are delegated to my legacy application, either via API of that application, or directly accessing the legacy DB?
If so, are there any examples or how-tos for this?
Yes, its trivial to integrate existing users with IdentityServer. The really nice thing is that all you need to is to implement the IProfileService interface.
IdentityServer never writes to the user database, its read-only. So its just a simple load operation that you need to implement to get it to work.
Also see this link and this link
The latest version of ASP.NET includes the new authentication framework ASP.NET Identity, which should be the core building block for user management in all new and near future ASP.NET projects and websites.
I have seen that it can integrate with the WebAPI quite nicely, but haven't seen any example of integration as authentication for mobile client devices. For example - suppose I have a ASP.NET website with Identity implemented in use. Now I want to build client applications for Windows 8.1 and Windows Phone 8. I see two main issues that are limiting this.
Firstly - ASP.NET Identity apparently issues only short-lived auth. tokens, which is quite a bad user experience for mobile applications. I have seen some attempts to create a refresh token mechanism - http://leastprivilege.com/2013/11/15/adding-refresh-tokens-to-a-web-api-v2-authorization-server/ . This is quite a nice approach, but it would still be more interesting to see a really built in solution.
Second - and maybe more important - external authentication provider support. On the ASP.NET Identity website it is quite clear and easy to see a way to authenticate via WebAPI, but I haven't seen this in use with external authentication. How is it possible to get the authentication URLs for Facebook, Microsoft and Twitter and how can the authentication flow be completed from within the app?
Has anyone some experience with this? It would be great to find a complete walkthrough, I will gladly reward the correct solution with some bounty points :-) .
The problem is that security is complicated and that Microsoft's solutions only address the simple scenarios.
Also, you're consing terminology (which increases everyone's confusion, including your own). ASP.NET Identity manages users' credentials stored in a database. It's unrelated to the type of application that needs to validate credentials (mobile, api, browser, desktop, etc).
Katana middleware is what allows an application to authenticate the caller. There's cookie middleware for browser applications, external middleware for google, facebook, WS-Fed, etc, and then there's OAuth2 for API applications. Each work differently based upon the nature of the application. Some of them interact as well, depending on the requirements of the application.
I don't mean to pick on you -- this is more of a complaint about Microsoft's lack of education/documentation in the frameworks they provide. And I suppose this is an answer to your question -- Microsoft doesn't have what you're asking for. They have bits and pieces, but you're left to connect the dots.
Some links that might help:
http://www.asp.net/identity
http://www.asp.net/web-api/overview/security
http://www.asp.net/vnext/overview/authentication
http://brockallen.com/category/owin-katana/
http://leastprivilege.com/category/katana/
http://leastprivilege.com/category/webapi/
HTH
I have a Classic ASP / VbScript website that I need to act as an SAML 2.0 Identitiy Provider.
Despite extensive searching I have been unable to find any resource / demo / example to steer me towards a solution.
As I can't find any information I am thinking that it is simply not possible, or is it so obvious nobody needs to ask or that is such an uncommon situation that no resource exists.
Further clarification added
My website.com is coded in Classic ASP / VbScript running in IIS7.5 on Windows 2008 server.
User logs into website.com and can now browse the site.
One section of website.com has links to other-website.com which ordinarily requires login.
To avoid this I can use SAML 2 based SSO to gain direct access to other-website.com by passing over EntityID and unique references from website.com database which correspond to other-website.com database to ensure authentication.
What I really don't understand is from the point that the User clicks hyperlink to other-website.com what I need to do to create and pass over the required information to other-website.com
I think that I have to create some form of encrypted XML document and then POST it via a form to the URL supplied by other-website.com - but I am not sure how to do this and can't find any sample / demo to help.
Hopefully that explains fully what I am trying to achieve!
The normal model is that you have a third-party product (ADFS, OpenAM, PingIdentity, ...) as your IP and your application is the RP (Relying Party).
You don't normally have an application as an IP.
What do you intend to authenticate against?
ADFS / WIF is based around ASP.NET not ASP.
WIF uses WS-Federation not SAML.
To use SAML you need ADFS and that runs on Windows Server.
Check out PingFederate and the Agentless Integration Kit from PingIdentity. Here's an overview of how the integration would work with your application - http://documentation.pingidentity.com/display/AIK12/Implementing+IdP+Functionality. PF would handle all the fancy standards-based requirements and your application would continue to maintain its own session and user authentication functionality. When SSO is needed, you then invoke the PF server. Once you integrate your app, it's very simple to add new service providers via the PF Admin Console.
[Note: I work for Ping]
For anyone reading this question, I would highly recomend taking a look at this article and sample code, I was in the same situation as the OP and found for me it was easier to use this C# ASP.Net code as a starting point (I have little experiance of C# but still got this working quickly and easily). It's clearly comented and works right out of the box and was easy to amend for my needs. In the end it was simpler to implement this in .NET and call it from my ASP application than create from scratch in ASP.
http://www.voiceoftech.com/swhitley/index.php/2008/09/single-signon-with-saml/
Currently, we have many web applications (external & internal) developed using Classic ASP through .NET 2.0 technologies. Each of those web applications have their own login screen authenticating against their own custom database or using Windows authentication. Users have access to one or more of these applications, meaning they have to log out and log back into applications that they would like to access. All applications share some part of the back-end data sources. Also, the business logic is embedded in the UI in addition to being duplicated across applications because there is no code/business logic sharing. Screenshot #1 gives a brief idea of the existing architecture.
Screenshot #2 shows the suggested architecture, which I hope will help in faster development, code/business re-usability and may be simpler maintenance. Users will access either external or internal url. In external, users will provide credentials and will be authenticated against custom database. In internal site, users will be automatically logged in using Windows authentication. After creating some samples, I have begun to like ASP.NET MVC 3. It keeps business logic separate from UI and I also like the unit testing capabilities.
Here are my questions:
Based on what I have found on the web so far, multiple authentications are not feasible within a single website. My understanding is that I have to host one website for each type of authentication (Forms and Windows). How do I redirect users to common landing page after they are authenticated so they can see the modules (links/menus) that they are authorized to access? Should I have to publish the same code set (dlls and content) to both the websites?
Has anyone faced a similar architecture problem? If yes, could you please share the challenges that you faced and how you tackled them? What are the industry standards in designing applications of this sort?
Does the suggested architecture make any sense or is it a really bad design? Are there any drawbacks in doing this in ASP.NET MVC 3?
I would really appreciate your inputs.
Thanks in advance.
I would set up a seperate web site which only handles the windows authentication. I would then rely on something like OpenID and/or OAuth to ask for credentials/token to make sure to user has proper access.
The user that want to sign in using windows credentials go through that process because you are right in that a IIS server running windows authentication is hard to mix with other stuff.
You can set up some kind of claim based network of thrust in which you applications get thier credentials from trusted sources and through that process you can negotiate and control access privileges cross many web sites. As long as your not doing custom hosting or white label branding you can have everything in one place (or even if you did you could design it so that you have a central solution of handing out authentication tokens).
Keep in mind the difference between Authentication and Authorization. You presumably want a single authentication mechanism (or maybe two, one for internal and one for external users). There is a similar post here that lays out some pretty good guidelines: How to allow multiple authentication methods in ASP.NET?
On one project we built a common controller class used in every page of the site. It handled authentication and access control. When a user tried to access any page it checked to see if they had a session identification cookie. If they did not they were required to authenticate(login). A challenge was doing a good implementation of the security. Current browsers have many flaws that make this difficult.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx