Originally I figured I would sidestep this issue until another time, but then when I started to auth the php service against the auth service, then connect to the metadata service to retrieve that data, I started to think that this is something that if I leave until another time, it'll be a pain in the ass to fix.
So I figured I would try to solve it now instead.
What I reasoned was that when you add a service to the system, it inevitably determines what users can authenticate by which repository type and which metadata can be retrieved since it's what does the retrieval of the data.
What I reasoned was that each repo service you start (php, npm, maven, apt-get) should have it's own key and the programmer for each service should be responsible for making these keys unique within a cluster of containers.
So lets assume satis/php gets the key "php"
When the service starts, all authentication requests should be tagged with repository_type=php since then the auth service can know which user to lookup, since a user could exist multiple times, but with different repositories (php and npm for example).
When a user is created, a repository_type field is required in order to create the user through the auth service directly. If the user is created through the php service, it'll tag automatically the repository_type=php so that'll be transparent.
If you create users directly through the auth service, whatever it attempting to create the user should be responsible for knowing the correct repository_type. I don't know how to enforce the repository_type is correct.
Perhaps the repo service when starting can register a repo type with the metadata service then you could retrieve a list of all valid repo types from this service?
Originally I figured I would sidestep this issue until another time, but then when I started to auth the php service against the auth service, then connect to the metadata service to retrieve that data, I started to think that this is something that if I leave until another time, it'll be a pain in the ass to fix.
So I figured I would try to solve it now instead.
What I reasoned was that when you add a service to the system, it inevitably determines what users can authenticate by which repository type and which metadata can be retrieved since it's what does the retrieval of the data.
What I reasoned was that each repo service you start (php, npm, maven, apt-get) should have it's own key and the programmer for each service should be responsible for making these keys unique within a cluster of containers.
So lets assume satis/php gets the key "php"
When the service starts, all authentication requests should be tagged with repository_type=php since then the auth service can know which user to lookup, since a user could exist multiple times, but with different repositories (php and npm for example).
When a user is created, a repository_type field is required in order to create the user through the auth service directly. If the user is created through the php service, it'll tag automatically the repository_type=php so that'll be transparent.
If you create users directly through the auth service, whatever it attempting to create the user should be responsible for knowing the correct repository_type. I don't know how to enforce the repository_type is correct.
Perhaps the repo service when starting can register a repo type with the metadata service then you could retrieve a list of all valid repo types from this service?