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
Related
I've searched over Internet and I couldn't find any good resources explaining how to authenticate an ASP.NET Core web application through ADFS using the SAML protocol.
However, I found an old blog post saying that it was not supported and that it would not be until at least .NET Core 2.1. Except of that, I didn't find anything else.
However, I can't believe that something so important is not yet supported...
Does anyone has any experience with that? Note that Azure is not an option here.
Yes you can - see this example using Sustainsys.
You can also use ComponentSpace (examples in that blog) or Rock Solid Knowledge as per this example.
Context:
I'm researching about how to easily implement SSO for an enterprise on-premise Service Provider to enable SAML and OIDC both. I came across multi-provider wrappers but I wasn't able to find python(tornado) specific ones.
Research:
The only active one I found is this but as it’s mostly for social and looks like it doesn’t support saml.
This link mentions some client based python wrappers like sanction, rauth but both doesn't support SAML
Apart from wrappers I also looked at dev tools provided by oneLogin for SAML protocol.
https://www.onelogin.com/resource-center/saml-toolkits
Python SAML OneLogin - How to support multiple Identity Providers
Questions:
which are the multi-provider authentication wrapper for python enterprise apps?
Are there other options apart from the ones mentioned above to ease the SP development?
Could I potentially use a wrapper like python-social-auth for OIDC support and OneLogin devtool for SAML support?
I'm a Product manager and not a dev. I have been researching a lot but to no avail.
python-social-auth supports SAML and OIDC. It supports multi-tenancy as well (overriding the default strategy).
I recommend you to use it rather than trying to implement them yourself if you want to save time/money or if your dev team has no much idea about authentication in general.
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
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.