Is it only possible to create public IT-systems in NemLog-in or not? I'm using the ITfoxtec Identity Saml 2.0 component. It looks like the ITfoxtec SAML 2.0 sample is configured with an IT-system for a private company.
The 'old' NemLog-in 2 supporting NemID only support public IT-systems. Where the new NemLog-in 3 supporting MitID (and NemID) both support public IT-systems an IT-systems for private companies.
Updated
The ITfoxtec SAML 2.0 sample is configured with a private IT-system in NemLog-in 3.
Related
I need to declare 2 IDPs in spring-security-saml having the same entity id.
My webapp uses spring-security-saml.
This webapp is accessible by 2 differents URLs behind a reverse proxy.
The first URL is public, the second URL is filtered.
So, I declared 2 SP (one for each URL).
Everything was working properly with a single IDP (ADFS or Gsuite).
I also run the application properly with 2 SPs and 2 IDPs with an affinity SP1/IDP1 and SP2/IDP2 when IDP1 and IDP2 had a different entity ID.
Unfortunately by wanting to use Azure Active Directory, each SAML application in Azure results in its own IDP metadata with its own certificate, but with the same entity id.
So I need to declare 2 IDPs in spring-security-saml having the same entity id.
Reading the code shows that it is not intended to work like this (the entity id is used as key).
Do you have an idea to work around this problem?
Should Azure provide a unique entity id ?
I know it is too old but just found it but you can not use the same Entity ID per tenant for 2 different apps, so it makes sense that the apps have a different certificate even if they have same Entity ID because both apps are in different tenants
How it worked for me!!
As Spring saml works only for unique IDP entityIds. So to make it unique for 2 different IDP having same entity Ids, I prexied one of it with alias as i know what is that alias is for.
So now I have to hack entityID at certain places of initialization, validation during metadata loading AND in SAML response verification.
For metadata(one that has prefixed entity Id) loading to be successful especially one with signed metadata..
Created new child class MySAMLSignatureProfileValidator that overrides
SAMLSignatureProfileValidator.validateReferenceURI.
To use this I need to create another custom class SamlSignatureValidationFilter that extends MYSamlSignatureValidationFilter and initialise MySAMLSignatureProfileValidator in their constructor.
Use this SamlSignatureValidationFilter when we add metadata to metadata manager like this..
metadataProvider.setMetadataFilter(new MYSamlSignatureValidationFilter(metadata.getTrustEngine(metadataProvider)));
And now add another custom class MYSAMLCachingMetadataManager to override initializeProviderFilters and remove the logic to setMetadataFilter as its already set as in above code.
Use MYSAMLCachingMetadataManager in your config for MetadataManager.
This should take care of saml metadata loading.
Then coming to SAML Response that has the issuer as the original entityId, we need to add prefixed alias to the context here so that it verifies with our prefixed_entityId stored in metadatamanager entity list.
In this case I added MySamlHttpPostDecoder that overrides HttpPostDecoder.extractResponseInfo to add alias to messageIssuer.
And, MySamlWebSSOProfileConsumerImpl to overirde WebSSOProfileConsumerImpl.verifyIssuer to set issuer.getValue with alias. so later verification with stored entitId will match.
Use this MySamlWebSSOProfileConsumerImpl and MySamlHttpPostDecoder in your config. To use MySamlHttpPostDecoder I need to add new class MySamlHTTPPostBinding(ParserPool parserPool, VelocityEngine velocityEngine, MessageDecoder decoder) that extends HTTPPostBinding and pass MySamlHttpPostDecoder for decoder.
Hope it works for you too!!!
I'm currently developing a back end and having my first run in with security laws etc. and it has complicated the design of my DB slightly:
Specification
Central server for app with DB containing limited user information (user_id, email, password (hashed and salted)) can be anywhere.
Organisations making use of our service require that all other information be stored in-house, so the database for that particular organisation is in their building.
The user IDs in our central database are used by multiple types of users in these organisations databases, where more info about that user is stored (phone number, name, address...)
Problem
With Spring Boot, I need to make it so the datasource used is determined by which user makes the request. I map users to their corresponding organisation's database within the central server so the information is there, but I'm not sure how to make this variable.
I understand there are methods involving adding another database config in the application.properties file. But as far as I'm aware this can't be changed (easily) once the server is deployed and running without a full redeploy, and I'm hoping to build this in such a way that adding another organisation only involves setting up their db, and adding another database details to the central server.
Extra detail
I'd like to use CrudRepository with hibernate entities for this. I plan on only generating user IDs on the central server.
Any pointers would be awesome.
Thanks!
The terminology for this is database multi-tenancy. There are multiple strategies for multi-tenancy: different databases, different schemas in the same database, and the same schema on one database with a defined discriminator.
You basically create a DataSourceBasedMultiTenantConnectionProviderImpl class which provides the connection to a datasource based on which tenant is requesting it, and a CurrentTenantIdentifierResolverImpl class which identifies who is the requesting tenant.
You can read more about it here. Since your tenants each have their own database, you would probably want to focus on the multi-tenancy separate database approach. It worked fine with CrudRepository when I implemented it. You also might want to find your own way of creating the tenant map, since I had 2 tenants and no need to add more at any point.
Heres a sample of the connection provider from when I implemented this:
public class DataSourceBasedMultiTenantConnectionProviderImpl extends AbstractDataSourceBasedMultiTenantConnectionProviderImpl {
private static final String DEFAULT_TENANT_ID = "A";
#Autowired
private DataSource datasourceA;
#Autowired
private DataSource datasourceB;
private Map<String, DataSource> map;
#PostConstruct
public void load() {
map = new HashMap<>();
map.put("A", datasourceA);
map.put("B", datasourceB);
}
#Override
protected DataSource selectAnyDataSource() {
return map.get(DEFAULT_TENANT_ID);
}
#Override
protected DataSource selectDataSource(String tenantIdentifier) {
return map.get(tenantIdentifier);
}
}
I am working with aspnetcore v2.1 (latest dev branches) in order to create a multi-tenant app where each tenant authenticates against their own Azure B2C AD tenant. This aproach was chosen so that email/password selections and social login associations are unique per-tenant.
Instead of a static ClientId applied in Startup.ConfigureServices, I want to apply the correct ClientId and Authority based on the current tenant identity (which I determine based on the hostname). Based on previous inspection of the 2.0-* code, I had been using an IOptionsSnapshot to allow me to apply the correct options as shown below.
In Startup.ConfigureServices:
services.AddSingleton<IOptionsSnapshot<OpenIdConnectOptions>, OpenIdConnectOptionsSnapshot>();
services.AddAuthentication().AddCookie().AddOpenIdConnect();
In Startup.Configure:
app.UseAuthentication();
With an implementation of :
public class OpenIdConnectOptionsSnapshot : IOptionsSnapshot<OpenIdConnectOptions>
However, now I find that my OpenIdConnectOptionsSnapshot is no longer being instantiated or referenced.
What is the correct way to apply a dynamic per-tenant ClientId, Authority, etc under AspNetCore Security 2.1.0-*?
(I am open to "you're doing it completely wrong" and suggestions of different ways to achieve multi-tenancy for tenants that have no pre-existing AzureAD footprint)
Try using IOptionsMonitor instead, we changed how IOptionsSnapshot worked fairly late in 2.0 and switched auth over to use the monitor instead.
OptionsSnapshot is now scoped
I've created a 'customerId' user attributes in my development AD B2C tenant. When querying these via the graph API I now get the following;
"extension_b0ba955412524ac8be63e24fa7eb0c23_customerId": "2"
Perfect! I use JSON.Net to convert this to a strongly typed object, and hence my POCO has the following property.
public string extension_b0ba955412524ac8be63e24fa7eb0c23_customerId { get; set; }
Not great, but I can live with it. My concern is that when I create these properties in our staging and production environments, the attribute names will change and I will have to rewrite a lot of code. How do I migrate these user attributes to our other environments, ensuring the property names do not change?
Custom user attributes in Azure AD B2C will always have a guid in the name that's unique per Azure AD B2C tenant.
This guid is the Application ID of the 'b2c-extensions-app' and will be the same for all custom attributes within a tenant, but different across tenants.
Given this behavior, you could make the code that handles custom user attributes dynamic such that it derives the full name* using the following pattern:
extension_<appId>_<attributeName>
And obtain the appID via the Graph:
https://graph.windows.net/yourtenant.onmicrosoft.com/applications?$filter=displayName eq 'b2c-extensions-app'
Of course, you can always provide feedback requesting that this is made easier in in the Azure AD B2C feedback forum.
In every IdentityServer4 Quick Start sample there are in-memory providers given for the resources, clients, and users. Are there any samples of the proper interface overrides needed for production?
For instance IProfileService is the class to be overridden for user management, however there are no examples that use this class and there is no specification in the reference section as to what the members of this class are. When implementing it you get the methods you need to override, but all the return types are Task and there is no helpful commentary on the specifics.
I had the same problem, and ended up looking at the default implementations (the way the IdentityServer4 implements these interfaces) here.
There's no IProfileManager so if you mean IProfileService here's how we're using it (to add claims to the access_token):
public Task GetProfileDataAsync(ProfileDataRequestContext context)
{
var claims = new List<Claim>();
context.IssuedClaims = claims;
return Task.FromResult(0);
}
You can now add your claims to that claims list and they will be added to the access_token which will be returned to the client.