ComponentSpace
|
|
ComponentSpace Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
You're welcome!
Regards ComponentSpace Development
|
|
|
akow
|
|
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 Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
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
|
|
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 Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
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
|
|
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
|
|
Group: Forum Members
Posts: 38,
Visits: 175
|
+xSorry 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 Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
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
|
|
Group: Forum Members
Posts: 9,
Visits: 114
|
+x+xSorry 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 Development
Group: Administrators
Posts: 3.2K,
Visits: 11K
|
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
|
|
|