ComponentSpace

Forums



SAML Multi-Tenancy Applications


SAML Multi-Tenancy Applications

Author
Message
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9K
You're welcome!

Regards
ComponentSpace Development
akow
akow
New Member
New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)

Group: Forum Members
Posts: 2, Visits: 15
Hi, we use DB as configuration store and our problem ist that loading all service provider configuration at once is to slow. Users need to wait on coldstart some sec. We write admin backend to manager configuration on the fly.
What we need is to load service provider configuration by name e.g.:

configProvider.GetServiceProviderConfigurationByName("http://localhost/ExampleServiceProvider2")
or
configProvider.GetServiceProviderConfigurationByName("http://localhost/ExampleServiceProvider2", "tenantID1")
for multi-tenancy applications.

We would cache the config loaded for some time to get more performance. This is would be much faster than loading all config at once or restart the whole application on config changes.
Is there an interface we can use to implement this behavier? Or any plans to write such abstraction provider.

Any further ideas?

Thank you in advance.

Best Regards

Alexej

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9K
Hi Alexej
Just to confirm, you would like to see an interface that allows you to control the loading of the SAML configuration and specifically so it can be loaded piecemeal and as required?
How many service provider configurations are you loading?
Is it possible to speed up the database access?




Regards
ComponentSpace Development
akow
akow
New Member
New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)New Member (2 reputation)

Group: Forum Members
Posts: 2, Visits: 15
Just to confirm, you would like to see an interface that allows you to control the loading of the SAML configuration and specifically so it can be loaded piecemeal and as required?

Correct.
How many service provider configurations are you loading?

at the moment 11 but there are much more to come. (we use EntityFramework Core)
Is it possible to speed up the database access?

I am working on it but, this would be still an issue if we load whole config at once.
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9K
Thanks for the information.
We'll discuss this internally to see what's the best way to provide this functionality.
Please email us mentioning this topic so we get your feedback of any proposals.

Regards
ComponentSpace Development
james.garrett
james.garrett
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)

Group: Forum Members
Posts: 9, Visits: 114
Sorry for bumping an old thread, but I found this in the search and it's exactly what I'm attempting.

Currently, we use this code to authenticate within our AssertionConsumer page, but only allow one IDP at a time.

try
    {
      var samlConfigs = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web");
      var samlConfig = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web").First();
      var samlConfiguration = BuildSamlConfiguration(samlConfig, _siteNameResolver.SiteName);
      // set the SAML configuration to the current one before we InitiateSSO
      SAMLConfiguration.Current = samlConfiguration;

      var isInResponseTo = false;
      string partnerIdP;
      SAMLServiceProvider.ReceiveSSO(request, out isInResponseTo, out partnerIdP, out userName, out attributes, out targetUrl);
    }
    catch (Exception)
    {
      rv.IsSuccess = false;
      rv.ErrorMessage = "There was an error attempting to log in via the SAML single sign on gateway. Please contact support for further assistance.";
      return rv;
    }


My question is if we went to a multi-tenant setup, what would we do to know what the user's saml config the assertion is for? Or is that automatic?


dmarlow
dmarlow
Junior Member
Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)Junior Member (55 reputation)

Group: Forum Members
Posts: 38, Visits: 175
james.garrett - 1/11/2018
Sorry for bumping an old thread, but I found this in the search and it's exactly what I'm attempting.

Currently, we use this code to authenticate within our AssertionConsumer page, but only allow one IDP at a time.

try
    {
      var samlConfigs = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web");
      var samlConfig = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web").First();
      var samlConfiguration = BuildSamlConfiguration(samlConfig, _siteNameResolver.SiteName);
      // set the SAML configuration to the current one before we InitiateSSO
      SAMLConfiguration.Current = samlConfiguration;

      var isInResponseTo = false;
      string partnerIdP;
      SAMLServiceProvider.ReceiveSSO(request, out isInResponseTo, out partnerIdP, out userName, out attributes, out targetUrl);
    }
    catch (Exception)
    {
      rv.IsSuccess = false;
      rv.ErrorMessage = "There was an error attempting to log in via the SAML single sign on gateway. Please contact support for further assistance.";
      return rv;
    }


My question is if we went to a multi-tenant setup, what would we do to know what the user's saml config the assertion is for? Or is that automatic?


One way is when you're creating and giving your metadata away to put an identifier into the URLs. For example, in your ACS endpoint that the IdP configures, you can put a special code that identifies the config to use (http://acme.com/acs/123). Then, in the SamlController, your ACS endpoint would look like this:


public ActionResult ACS(string id)
{
    // id parameter is the tenant
    try
    {
      var samlConfigs = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations(id);
      var samlConfig = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations(id).First();
      var samlConfiguration = BuildSamlConfiguration(samlConfig, _siteNameResolver.SiteName);
      // set the SAML configuration to the current one before we InitiateSSO
      SAMLConfiguration.Current = samlConfiguration;
      var isInResponseTo = false;
      string partnerIdP;
      SAMLServiceProvider.ReceiveSSO(request, out isInResponseTo, out partnerIdP, out userName, out attributes, out targetUrl);
    }
    catch (Exception)
    {
      rv.IsSuccess = false;
      rv.ErrorMessage = "There was an error attempting to log in via the SAML single sign on gateway. Please contact support for further assistance.";
      return rv;
    }
}


ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9K
Just as a note, the interface referred to earlier was introduced in v2.8.4.
It's the ISAMLConfiguartionResolver under the ComponentSpace.SAML2.Configuration.Resolver namespace.

Regards
ComponentSpace Development
james.garrett
james.garrett
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)

Group: Forum Members
Posts: 9, Visits: 114
dmarlow - 1/11/2018
james.garrett - 1/11/2018
Sorry for bumping an old thread, but I found this in the search and it's exactly what I'm attempting.

Currently, we use this code to authenticate within our AssertionConsumer page, but only allow one IDP at a time.

try
    {
      var samlConfigs = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web");
      var samlConfig = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations("Web").First();
      var samlConfiguration = BuildSamlConfiguration(samlConfig, _siteNameResolver.SiteName);
      // set the SAML configuration to the current one before we InitiateSSO
      SAMLConfiguration.Current = samlConfiguration;

      var isInResponseTo = false;
      string partnerIdP;
      SAMLServiceProvider.ReceiveSSO(request, out isInResponseTo, out partnerIdP, out userName, out attributes, out targetUrl);
    }
    catch (Exception)
    {
      rv.IsSuccess = false;
      rv.ErrorMessage = "There was an error attempting to log in via the SAML single sign on gateway. Please contact support for further assistance.";
      return rv;
    }


My question is if we went to a multi-tenant setup, what would we do to know what the user's saml config the assertion is for? Or is that automatic?


One way is when you're creating and giving your metadata away to put an identifier into the URLs. For example, in your ACS endpoint that the IdP configures, you can put a special code that identifies the config to use (http://acme.com/acs/123). Then, in the SamlController, your ACS endpoint would look like this:


public ActionResult ACS(string id)
{
    // id parameter is the tenant
    try
    {
      var samlConfigs = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations(id);
      var samlConfig = _samlConfigurationQueryFunctionality.GetActiveSamlConfigurations(id).First();
      var samlConfiguration = BuildSamlConfiguration(samlConfig, _siteNameResolver.SiteName);
      // set the SAML configuration to the current one before we InitiateSSO
      SAMLConfiguration.Current = samlConfiguration;
      var isInResponseTo = false;
      string partnerIdP;
      SAMLServiceProvider.ReceiveSSO(request, out isInResponseTo, out partnerIdP, out userName, out attributes, out targetUrl);
    }
    catch (Exception)
    {
      rv.IsSuccess = false;
      rv.ErrorMessage = "There was an error attempting to log in via the SAML single sign on gateway. Please contact support for further assistance.";
      return rv;
    }
}


Thanks, I was hoping that the receive SSO method would be able to detect the entity id and I wouldn't need to do that.  ComponentSpace, any feedback?
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)ComponentSpace Development (4K reputation)

Group: Administrators
Posts: 2.9K, Visits: 9K
We don't attempt to determine which SAML configuration should be used. This is the responsibility of the application.
In a multi-tenanted configuration there's one SAML configuration per tenant. Each configuration includes a unique configuration ID.
Prior to any SAML SSO API call, you need to specify the correct configuration ID so we know which configuration to use when processing the SAML SSO.
This is done by setting the SAMLController.ConfigurationID property.
For example:
SAMLController.ConfigurationID = "tenant1";
SAMLServiceProvider.ReceiveSSO(...);
This assumes that there's a SAML configuration whose ID is "tenant1".
Determining which configuration to use is the responsibility of the application.
If each tenant has a separate subdomain name, this can be used by the application as the tenant name (ie configuration ID).

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 4 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....









Forums, Documentation & Knowledge Base - ComponentSpace


Search