Are there any examples of using itfoxtec-identity-saml2 with asp.net core Identity.
Specifically, I have many SAML Idps (https://stubidp.sustainsys.com, Okta, Auth0, Salesforce, etc) and I want to add them using AuthenticationBuilder.
public static class Saml2Extensions
{
public static AuthenticationBuilder AddSaml(this AuthenticationBuilder builder, string authenticationScheme, string displayName, Action<Saml2Options> configureOptions)
{
...
}
}
A good example would have a mix in of Google, Azure both using OIDC, and a few SAML ones.
I'm afraid that I do not have sutch an example. I always put a proxy / broker IdP in between, in my case I use FoxIDs. That way the application only need to know about one IdP and would then ask the broker IdP to handle the up-stream IdP authentication.
Related
We are using the ITfoxtec SAML2 library for Single Sign On with SAML2 authentication for some of our external Clients.
So far we only have one client that wants SSO, but we anticipate that we will get more clients that want to use SSO, so my question is that can we store the setting in a Database rather than read from a Configuration file.
We would like to look up the values for each client from a data store and then build the SAML2 Configuration and then do the binding.
var binding = new Saml2RedirectBinding();
binding.SetRelayStateQuery(new Dictionary<string, string> { { "RelayState", relayStateReturnUrl ?? Url.Content("~/") } });
//The bindingResult is a SAML2 redirectBinding - this create a browser redirect to the IDP.
var bindingResult = binding.Bind(new Saml2AuthnRequest(_samlConfig));
So we would build out the Saml2Configuration our selves (Or perhaps store those in a Database table and look it up based on the client.
The idea is to pass in a custom SAMLConfiguration rather than reading it from the App settings.
Would this approach work, would the ITfoxtec have a sample for this approach ?
Multible IdP and RP support is implemented in FoxIDs in the SamlConfigurationLogic.cs class. You can either implement you own version of the SAML config logic or user FoxIDs to handle the multible IdP connections for your application.
Related questions and answers:
ITfoxtec SAML 2.0: Dynamic configuration
Load SAML2 configuration on the runtime instead of loading it on the Startup
Previously our web application (NET Framework 4.8) was using Windows Authentication, then we switched to Sustainsys/Saml2 with Startup.cs and OWIN to login.
It turns out that SAML login cannot be used by Task Scheduler/CRON and by external API consumers, because SAML requires human interaction. So SAML must be disable and other Authentication must be used for the following pages:
background scripts (aspx pages) run by Task Scheduler;
3rd party application use some of our APIs GET/POST;
Task Scheduler do not support saml2 and so and external 3rd party apps, they connect via stored in their config login/password.
As far i know SAML2 requires human interaction via web popup (azure in our case) and cannot be automated.
Issue was solved by using OAuth (token) along with SAML. If OAuth is put before SAML in OWIN Startup.cs, token API will work even is SAML is activated (i think SAML code see that Thread.CurrentPrincipal is already set, so SAML step is skipped)
using System;
using System.Web.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Owin;
using Owin;
using BundleTable = System.Web.Optimization.BundleTable;
////
[assembly: OwinStartup(typeof(MyApplication.App_Start.Startup))]
namespace MyApplication.App_Start
{
public class Startup
{
// Configure the HTTP request pipeline.
public void Configuration(IAppBuilder app)
{
ServiceCollection services = new ServiceCollection();
ConfigureServices(services);
OAuthConfiguration oauthConfig =
MyConfigurationManager.ReadOAuth();
OAuthSetup oauth = new OAuthSetup(app, oauthConfig);
/* server + consumer
IdentityServer 3
// server. Probably this step can be skipped if use Azure as server
app.Map(configuration.AuthServerUrl, idsrvApp =>
{
idsrvApp.UseIdentityServer(options);
});
//consumer
app.UseJwtBearerAuthentication,
app.UseClaimsTransformation */
oauth.Use();
SamlConfiguration samlConfig =
MyConfigurationManager.ReadSaml();
SamlSetupSustainsys saml = new SamlSetupSustainsys(app, samlConfig);
/*
Sustainsys
app.UseSaml2Authentication(options);*/
saml.Use();
WebApiConfig.Register(config);
app.RequireAspNetSession();
app.UseWebApi(config);
BundleTable.EnableOptimizations = false;
BundlingConfig.Register(BundleTable.Bundles);
}
// Add services to the container.
public void ConfigureServices(IServiceCollection services)
{
//services.AddMvcCore();
}
}
}
I use Okta as my IDP and I have 2 use cases:
IDP-initiated SSO
when a user wants to login using his okta credentials to my system, I redirect him to okta, and okta send the response to a callback in my app.
I was wondering why I need the keystore? how is it used?
The messages to the IDP from the SP (my app) will be encrypted using this keystore key-pair? And if so, doesn't that mean that I need to somehow share my keys with okta?
I couldn't find any explanation on this.
Appritiate any help on this!
Thanks!
SAML Responses sent from a SAML Identity Provider ("IdP") like Okta will be signed using Okta's private key, these messages will be validated by a SAML Service Provider ("SP") like your application using the corresponding public key.
In your case, the keystore should only be used for Okta's public key (or public keys, if you federate with more than one Okta org). You will not need to share any keys with Okta, but you will need to get the public key from Okta somehow. The best way to get the public key from Okta would be via an IdP metadata URL, the next best way would be to have the Okta administrator paste Okta's X.509 encoded public key into your app somehow.
I'm in the process of implementing AAD single sign on in our application and we will be using the adal.js/adal-angular.js library with our MEAN stack application. Part of initializing the library is to call init() and provide the tenant and clientId
adalProvider.init(
{
tenant: "mycompany.onmicrosoft.com",
clientId: "05bdd8d7-XXXX-XXXX-XXXX-5f2769f8b9b6"
},
$httpProvider
);
for example.
If someone views the source and takes the tenant and clientId can they use that somehow in their own application maliciously?
Does AzureAD check the URL the request came from and block it if it's not the configured login url?
Seems as though the clientId is more like a public key but if the only 2 things needed for an app to trigger authentication with AzureAD is the tenant and clientId and those are exposed client side in source code that someone could use them to create a phishing site X or to grab id_tokens if the request is redirected back to their site X rather than the original site
Does Azure rely on the configured settings in the application setup and protect against this?
I'm still getting a grasp on the OpenID Connect and OAUTH 2.0 finer points so forgive me if this question has an obvious answer.
Adal.js uses the Implicit flow (as per OpenID connect / oAuth 2 specifications) and exposing the ClientID (and tenant id of AAD) doesn't pose any security risk.
While registering the Clients in Azure AD administration panel, we specify a Redirect URI for the client. This is the Application URL for which users will get redirected after successful authentication.
So even if a malicious client tries to use your clientid and tenant id, the users will be redirected back to the registered URI(which is your app) after authentication and not to the malicious site
In implicit flow the application doesn't collect any username / password, IDP/OP (i.e AAD) manages this part - so user credentials won't be compromised as well
**For other flow types (Authorization code, Client credentials,etc) we have something called client-password along with ClientID. This shouldn't be exposed to public clients.
In WSO2IS v4.6.0, the AuthnContextClassRef value is hardcoded to urn:oasis:names:tc:SAML:2.0:ac:classes:Password. In fact, the SAML SSO endpoint actually authenticates users via HTTPS by default and the AuthnContextClassRef value in this case should be urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.
What's the best way to correct this or get this issue on WSO2's radar?
I've created a JIRA ticket for this issue: https://wso2.org/jira/browse/IDENTITY-2585
While waiting for an offical fix, you can override their DefaultSAML2SSOManager by specifiing your own class in repository/conf/security/application-authentication.xml with:
Parameter name="SAML2SSOManager">my.version.of.SAML2SSOManager
I use a slightly modified version of their DefaultSAML2SSOManager and am able to connect to our IDP.