My company is in need of a federated identity solution, and being a Microsoft shop, we're looking to use MS technologies to accomplish this goal.
We don't have Server 2008 or .NET 3.5 in production, so we're limited to a .NET 2.0/Server 2003-based solution.
This means (in terms of a federated identity solution), Active Directory Federation Services.
ADFS looks pretty good because it supports the WS-Federation standards, which means we can federate with partners not using Microsoft technologies.
Unfortunately (for us), Microsoft is close to releasing a .NET 3.5-based identity framework, the Geneva Framework.
The Geneva framework appears to be better than ADFS in every way (mostly because it's ADFS plus additional functionality and standards support).
Since we're not a .NET 3.5 shop and Geneva is only in beta, it's not a viable option for us at this time.
My question is this: how hard will it be for us to move from ADFS to Geneva?
We're just at the proof-of-concept phase with ADFS, so we haven't started diving into the code changes required to move from identity-based authorization to ADFS claims-based. I'm sure we can put this logic in an assembly that can be updated to support Geneva claims-based authentication.
Along with the code changes required, how difficult will it be to migrate our claims-based infrastructure from ADFS to Geneva? (e.g. Moving from ADFS's STS (Federation Service) to Geneva's STS (Geneva Server))
Thanks for any input on this topic, it's greatly appreciated!
I received a response on an MSDN forum post:
Although I haven't done it myself, but it should be pretty safe to anticipate moving from ADFS to Geneva should be qute plesant journey. By that time your RP will be already claim-based application so there's no big leap there; and Geneva facilitates configurations by autoconfig based on metadata exchanges.
Related
I am in need of a solution for using ADFS 3.0 identities in a ASP.NET Core 2 Web Api application. The Windows Enterprise Support team at my organization has informed me that they are only familiar with SAML or WS-Fed based relying parties within ADFS, and are not interested in allowing me to help them configure OAuth, which I could consume directly within the application. As far as I am aware, neither SAML nor WS-Fed are compatible with anything currently available targeting netcore or netstandard.
I've been looking at Identity Server 4, and it's so-called "Federation Gateway" functionality, but I can't find much in the way of documentation. Is this something that could be useful for my use case? I'm guessing that it's only set up to interface via OAuth or OpenID, but I could be wrong.
I've also looked at using Amazon Cognito as the middleman to issue JWTs based on the SAML response, but after I got a proof of concept working with this configuration, I realized the cost at $0.45/MAU is prohibitively high, as the application will have around 10-15k regular users.
If Identity Server isn't the solution, are there any other similar "Federation Gateway" type solutions available as preferably open source/free software? Even if the solution wasn't .NET-based, I'd be interested in looking at it. I'm toying with the idea of building something like this in Java or Ruby as a last resort.
As of version 2.0, IDS4 can be a WS-Fed relying party. This would allow it to act as a middleman between ADFS and OIDC/OAuth RPs.
This vid from the IDS4 guys covers the available options: https://vimeo.com/254635632
It's also worth noting that you can run ADFS 2016 servers in a 2008R2 or higher domain and that natively supports OpenID Connect but given what you've said about your internal "support" team, deploying IDS4 may be a better option, although probably more work.
Just for completeness, the issue with WS-Fed was cyptographic support in .NET Core. This is now resolved so WS-Fed is supported.
SAML support is available via Sustainsys or Rock Solid Knowledge.
You can implement SAML 2.0 federation with AD FS 3.0 in ASP.NET Core 2.1 using the ITfoxtec Identity Saml2 package. NuGet package: https://www.nuget.org/packages/ITfoxtec.Identity.Saml2.MvcCore/
Project https://itfoxtec.com/IdentitySaml2 and code samples https://github.com/ITfoxtec/ITfoxtec.Identity.Saml2/tree/master/test
In an attempt to understand what I may use for OpenId Connect Server implementation, I have looked into what each of them is:
IdentityServer4:
an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2.
AspNet.Security.OpenIdConnect.Server:
is an advanced OAuth2/OpenID Connect server framework for both ASP.NET Core 1.x/2.x and OWIN/Katana 3.x/4.x, designed to offer a low-level, protocol-first approach.
OpenIddict:
OpenIddict aims at providing a simple and easy-to-use solution to implement an OpenID Connect server in any ASP.NET Core 1.x or 2.x application.
OpenIddict is based on AspNet.Security.OpenIdConnect.Server to control the OpenID Connect authentication flow and can be used with any membership stack, including ASP.NET Core Identity.
Also have checked that all of them use well the ASP.NET Core Identity as a membership system.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Have I missed something, or this is how things in general are?
EDIT (01/28/2021): as part of the 3.0 update, AspNet.Security.OpenIdConnect.Server and OpenIddict were merged to form a single/unified codebase under the OpenIddict umbrella, which should offer the best of both worlds: you still have the same experience as before, but can now opt in for the degraded mode, giving advanced users the same lower-level approach as AspNet.Security.OpenIdConnect.Server.
And so my current understanding is that IdentityServer4 and OpenIdConnect.Server are two alternative frameworks that solve the same problem. The main difference is the list of supported ASP.NET Core versions.
Actually, I believe the most important difference is that these two libs don't share the same objective. ASOS' only mission is to help you deal with the raw OAuth 2.0/OIDC protocol details: everything else is totally out of scope. Concretely, this means that concepts like users, applications or stores - that you can find in OpenIddict and IdentityServer - are completely inexistant in ASOS (which means you're free to bring your own implementation... and your own abstraction).
While IdentityServer will expose many abstractions and services allowing to configure specific features, ASOS - that was forked from Katana's OAuthAuthorizationServerMiddleware - has a centralized low-level events-based API (named OpenIdConnectServerProvider) that behaves exactly the same way as the ASP.NET Core security middleware developed by MSFT.
When working with ASOS, you have to deal with raw OpenID Connect requests and implement potentially sensitive things like client authentication (e.g using a database containing the client credentials) and that's why ASOS' core target is people who understand how the OAuth2/OIDC protocol work. OpenIddict and IdentityServer, on the other hand, will implement these things for you.
Regarding Openiddict - it is a kind of extension to simplify server creation based on AspNet.Security.OpenIdConnect.Server.
Initially, that's indeed how I was asked to design it. OpenIddict was created for non-experts who don't feel super comfortable with the protocol details of OAuth 2.0 and OpenID Connect.
While it will give you full flexibility to implement the user authentication part (e.g in your own authorization controller, using ASP.NET Core Identity or your own authentication method), it will handle the complex request validation process and make it transparent for your app, without drowning you with tons of configuration options.
Unlike ASOS (that tries to be as flexible and as close to the specifications as possible), OpenIddict generally comes with more restrictive validation routines that I personally consider as best practices. For instance, it will automatically reject authorization requests that contain response_type=token if the client is a confidential application, even if that's not prohibited by the OpenID Connect specification.
Windows Identity Foundation (WIF) is around for a while, may be 5 to 7 years or more!, now Microsoft made WIF part of .net framework (4.5) itself. As we know WIF is a middleware for building identity aware applications.
As the trend on the web technology is changing, we have now need to incorporate multiple other identity providers (Google, Facebook etc.), in our application.
Now the industry got other Middleware technologies like OWIN, ASP.NET Identity etc.,
My Question,
Is still the WIF relevant and do we need to consider using it for new projects?
Or
Do we need to implement OWIN as alternative middleware? (As I understand Microsoft is betting on OWIN / KATANA moving forward).
Please share your thoughts.
For new projects I highly recommend considering Katana and ASP.NET 5 OWIN middleware.
WIF remains supported as part of the .NET framework, however we stopped adding new features long ago - all the innovation has been poured in Katana and OWIN middleware in general. Also, we like to think that the OWIN middleware is significantly easier to use :) Again, if your project has legacy aspects that impose the use of WIF, you can go ahead knowing we'll support you: but if you have any chance of choosing, the OWIN middleware is the best path moving forward.
Totally agree with #vibronet but to answer the question - yes - still relevant.
There's a ton of WIF out there - I support lots of customers who still use it.
OWIN is easier to use but the nice thing about WIF is that everything is in the web.config so the details are more explicit and easier to change. However, that comes at the cost of a fairly steep learning curve.
Refer: OWIN : Differences with WIF and WIF : Wrappers around protocols.
As per the links:
"You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.
It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical."
Also consider we have moved some of the functionality of WIF into an open source project we refer to as Wilson. You can check it out here: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
I am dumb and don't know what these two frameworks provides. I wanted to move to claims based authentication and don't understand what these two frameworks provide to me. Are these two providing the same functionality just named differently or they have a purpose?
Is there a question on SO that will help me getting started with porting existing forms authentication application to "Claims Based Authentication" ?
thank you very very much for your answers
Geneva is now called Active Directory Federation Services (ADFS).
It is a Security Token Service (STS) which issues signed tokens containing attributes about a user (name, email etc.)
WIF is the set of classes you include in a ASP.NET application that provides the plumbing to connect to ADFS.
Have a look at:
A Guide to Claims-Based Identity and Access Control
AD FS 2.0 Content Map
Windows Identity Foundation (WIF) Content Map
Update
The WIF link above contains a link to Get Started with Windows Identity Foundation (WIF) which includes the Identity Training Kit and some "Getting Started" examples.
I'm about to begin building an e-commerce website using c#, ASP.Net MVC 2, IIS7 and SQL 2008. The site will allow users to login, make purchases, and manage their orders. Obviously, there's a need for strong security here. I've been searching around on SO and Google for a single definitive guide that covers enough on security to allow me to...
learn where security needs to be a consideration and...
how to implement it properly on the Windows stack.
This will be my first e-commerce site that I'm building from scratch. Is there a definitive or idiots guide to implementing strong web security for all aspects of an e-commerce site using ASP.Net MVC 2/SQL 2008?
Thanks so much in advance for all your help!
"Definitive" and "idiots guide" seem a little mutually exclusive, but here's a few I've seen before that deal with general ASP.NET security and some specifically for MVC:
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (Microsoft, MSDN)
Developer Highway Code (Security - MSDN - Microsoft UK)
Improving Web Application Security: Threats and Countermeasures (Microsoft, MSDN)
The HaaHa Show: Microsoft ASP.NET MVC Security with Haack and Hanselman (Microsoft Video)
There's also some tutorials on http://www.asp.net/mvc/security about preventing javascript attacks. Basically this boils down to always HTML encoding any output.
As for SQL 2008, normal best practice would be to use Windows Authentication and only grant read/write access to the tables you have to.
Start with OWASP.
OWASP is the authority on Web Application Security. Their list of top ten vulnerabilities is the bible for web security.
Try here for OWASP overview: http://www.owasp.org
And here for the OWASP top ten: http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
The latter link shows how to protect against these threats including .Net code.
Please see the MVC Security page on ASP.net.
They have a few good videos and their sample applications have been helpful to me.