Aws-sdk-ios: Best practice to store multiple configuration values

[ChrisInspect]

State your question
Regarding to Release 2.11.0 there is a new possibility to set the MobileClient-values at runtime. I used this feature to give every customer his own UserPool. At the beginning of my app the customer types in his "IdentKey" and depending on this key he retrieves his poolvalues. Every Poolvalue for every customer Is hardcoded inside my app. This can't be best practice. For now It works, but when we get a new customer, we want to give him access to his UserPool without updating the entire App with the new hardcoded values. Thinking about security, hardcoded values are also not advisable.
But where or how should I store these values? Is there a best practice for this use case?
mrublev's comment mentioned, that it would be useful to add the possibility to reconfigure MobileClient at runtime.
With this option it would be possible to:

• User logs in CustomerPool with Identkey and get his Poolvalues from e.g. DynamoDB.
• User logs out
• User logs in his UserPool

Any advise would be very helpful

Which AWS Services are you utilizing?
AWSCognito
AWSMobileClient

Environment(please complete the following information):

• Dependency Manager: [Cocoapods]
• Swift Version : [5.1]

[palpatim]

@ChrisInspect

The 2.11.0 feature allowing runtime specification of configuration values is a way to initialize from an in-memory object rather than a file. The intent is to support customers who for one reason or another didn't want to use a packaged awsconfiguration.json file to configure their application. Notably, we do not support overriding an existing configuration via this API, which means that if you use the SDK with one configuration, it is not supported to change it (as with a new user pool).

What use case are you trying to support? UserPools aren't intended to be a per-user resource; they're a user directory and lightweight authorization mechanism that is intended to be shared at an application level.

[ChrisInspect]

@palpatim
I want to separate my customers and handle their users in an easy way.
Instead my old approach using multiple user pools, I am thinking about using one user pool, as you suggested. Every customer will get one group for his users and with this group I can set permissions for this customer.
The only problem I am facing is, how can I separate my customers at the beginning of my app. (LoginScreen). I have to somehow look, which customer wants to login. I also have to prevent, that users have duplicated usernames. For example 'admin'. This was my problem, why I used multiple pools. Users from my customer don't want to login with phone number or email, only with username and password, so there is no unique identifier.

[royjit]

We are discussing this with the team. Will follow up here when we have more information.

[lawmicha]

Hi @ChrisInspect , I spoke with the Cognito service team and they said that "user management apps" are not supported, and so we don't have a recommendation as to how to approach building this.

Regarding your latest comment, the problem you are facing, "finding out which customer wants to login". It sounds like users belong in different user pools, and you have a single login that first needs to know which userpool to authenticate with? I think you will need a page that shows a directory of userpools that can be filtered or selected from. Once it is selected, then you would have retrieved the user pool details. Gather the credentials and you can instantiate the AWSMobileClient programatically. There are some implications of this as well since if you are creating new user pools in the future to be added to that directory, then the authenticated user would also need to have access to your downstream resources. AWSMobileClient is also not built to be deallocated and reinstantiated.

Could you provide more details as to what you are want the users of your app to be able to do? Understanding your use case will help us define the feature request for the client SDK and also for the service team.

[ChrisInspect]

Hi @lawmicha thank you for your answer,
our customers are companies with around 500 employees. At this companies some employees (e.g. on production machines) don't have an email-address from the company, because they don't need one. They also haven't company mobile phones, so the only possibility is that they can login to our app via username or something similar. Here is the problem.
Customer 1 will get an user "admin", but customer 2 will also get one. Now I have to somehow separate my customers before they login with their usernames, to know which customer wants to login. Another problem is, if customer1 wants to create a user for example named "Micha", but customer2 already has a user with this name, customer1 can't create it. For now every customer has his UserPool with IAM-Permissions to his bucket, dynamodb-table, etc.

Now I thought about creating a public DynamoDB-Table, where I store an UUID for every customer. Based on a keyword at the login screen, every customer will get his UUID. This UUID will be set in front of every username, before they login, so I can separate them by customer.
Example:
Customer1 has UUID:"12345" and keyword:"One"
admin from customer1 wants to login, so he types in the customer-keyword "One"
Now the app grabs the UUID from the public DynamoDB-Table and set it in front of his username
So when admin now wants to login his 'invisible' username is 12345#admin. Now I know, that this user is from customer1

But I don't know if this is a good approach/solution?

[palpatim]

@ChrisInspect We don't really have a good story for multi-tenant applications such as you're describing. There are a number of complications and security implications to supporting such use cases, as you're already discovering, and it's not a widely-requested feature for us.

The best advice we can give right now is to use a standard code base for your executable code but distribute the application with customer-specific configurations, with each configuration pointing to the appropriate, isolated, customer-specific backend resources.

There may be other ways of accomplishing this, but our general guidance is that you're going to want your app to be targeted to exactly one configuration, rather than picking and choosing from a set.

[ChrisInspect]

@palpatim sounds like the best solution. Thank you.