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?
Related
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'm currently developing a web application that will use Facebook as a authentication service. Does it make sense to implement it as an ASP.NET Forms Authentication custom membership provider? While I made my research, I didn't come across any concrete significant advantage of using the Forms Authentication. However, it instinctively seems to me as a good thing to do, because aside from creating a completely custom implementation of authentication using Facebook, I didn't find any extensibility point inside ASP.NET where I could plug in the Facebook auth behavior.
Can you then tell me whether the Forms Authentication is a good idea or not. And if not, is there any other way than completely custom code (I'd like to avoid managing the session cookies, loading the current user, etc. manually).
I'm using ASP.NET MVC 3, Entity Framework and I'd like to avoid the Facebook C# SDK (the extensive use of dynamic types is a bit of a turnoff for me :-) ).
Thanks for any advice.
A simple answer is to use .NET 4.5 oAuth templates, they are incredibly easy to link Facebook up to forms authentication.
http://www.asp.net/vnext/overview/videos/oauth-in-the-default-aspnet-45-templates
However you may struggle to find a decent server if you are planning on releasing immediately. In a couple of months plenty of servers will support .NET 4.5.
The OAuth templates work for both v4.0 and v4.5 so you can publish them onto a server today itself :)
I was tasked with creating an SSO solution from an existing asp.net app to a new sharepoint 2010 app.
The existing asp.net app uses forms authentication, but not against a single data source. It checks a database, active directory and a few mainframe tables to authenticate, and finally creates a forms authentication ticket.
I was looking to share the token between sp2010 and the asp.net app, but I am now realizing this is not possible, due to the fact the sp2010 does not use simple FBA tokens any more.
So now I am looking to go the STS and claims-based route. After looking in to it a little, I understand that using ADFS would be much better than building a custom STS for the asp.net side. My issue is that since I have the custom ticket creation authentication method on the asp.net side, I don't have a single data source to "feed" the adfs. I am new to sharepoint and adfs and I really don't know how to begin this type of integration.
Can anyone help me get my head around this?
Thank you!
ADFS attribute stores might solve your problem, although for this to make sense you would ideally integrate Windows Identity Foundation (WIF) into your application, which might be an intrusive change.
http://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores(v=ws.10).aspx
In short, ADFS is not limited to AD for collecting user data. You can configure it to query other user attribute stores, such as your database. You can then author rules within ADFS to tell it what queries to make, and ADFS will use these queries to populate user claims into the token that ADFS issues to your application.
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 am moving a legacy winform app to the web and would like some advice on forms authentication. Am I correct in assuming that forms authentication is better than rolling up my own user authentication functionality?
It would be easy enough to roll my own since the this is what the winform application did and the table structure already supports it, but forms authentication looks like it would do a much better job securing the site and the user authentication info.
I'm an old programmer, but pretty young in web dev and I have learned over the years that using MS built in tools sometimes looks better than it works...forms authentication isn't one of those cases is it?
Thanks!
I'd say that Forms Authentication is a case where you're likely to experience no "buyers remorse". You can opt in to use some pretty nice features. The model is very flexible because it allows you to implement your own Membership Providers.
Using forms authentication doesn't means you don't get to use those tables. You will do the check for username/password, and tell asp.net that the user is authenticated. Asp.net will continue from there, ensuring further requests from that user are identified and authenticated (based on an authentication ticket).
Update 1: Later on asp.net included membership providers, with some controls for it. Even then you can still implement your own membership provider, which in really simple cases you can do by implementing only 1 or 2 of the methods. If you have several features, and they don't map well with what the membership provider supports, I would stick to a custom implementation.