Group membership passthrough

[nonspecialist]

A single sshephalopod service for a domain (which is the way it's implemented at the moment) doesn't let you grant access to only some hosts under that domain. For example, if there are two applications or products hosted in a domain: ProductA and ProductB, and you want some developers to be able to log in to ProductA hosts, but not ProductB, you'd currently have to run 2 sshephalopod endpoints. Not fun.

If we can pass-through group memberships from the backend, we can map a username to a group membership; e.g. users in group Product-A-Developers could log in as producta-user but not as productb-user.

[nonspecialist]

There are currently two schools of thought on where the authorisation should live in the proposed flow:

1. In whatever is back-ending the identity provider (eg Active Directory). This could look like:

   dn: cn=Product-A-Users,ou=groups,dc=example,dc=com
   cn: Product-A-Users
   uniqueMember: cn=Some User,ou=people,dc=example,dc=com
   sAMAccountName: producta-user
   

   Sadly, it seems Difficult to pass attributes of groups through most IdPs that aren't the group name, though this is possibly because we haven't looked hard enough. This raises the ugly spectre of the suggestion to encode destination-username@destination-domain in the name of the group itself. This would work, but relies on string parsing within sshephalopod, which doesn't seem very robust to me.

2. In sshephalopod itself. This would mean that we'd have to have some way of configuring a mapping from authenticated-user to permitted destination-user@destination-domain tuples. Updating this would then require adding a configuration mechanism to sshephalopod (which is probably necessary anyhow, because right now a lot of things are hardcoded that shouldn't be) and adding support for something like:

   {
     "[email protected]": {
       "dns.domain.com": [
         "producta-user",
         "productb-ops"
       ]
     }
   }
   

   This configuration mechanism would have to handle being updated by Authorised Persons, ideally without having to redeploy the services.

3. Split the responsibility between whatever back-ends the IdP and sshephalopod; in this case, the IdP presents a simple list of groups that the authenticated user is a member of, and then sshephalopod decides what that means.

   For example (edited for brevity) the IdP returns:

   <saml2p:Response>
   ...
     <saml2:Assertion>
       <saml2:AttributeStatement>
         <saml2:Attribute Name="groups">
           <saml2:Attribute>Product-A-Users</saml2:Attribute>
           <saml2:Attribute>Product-B-Ops</saml2:Attribute>
           <saml2:Attribute>Product-C-Readonly</saml2:Attribute>
           <saml2:Attribute>Product-D-Ops</saml2:Attribute>
         </saml2:Attribute>
       </saml2:AttributeStatement>
     </saml2:Assertion>
   </saml2p:Response>
   

   and then sshephalopod has a config which says:

   {
     "Product-A-Users": [ "producta-user" ],
     "Product-B-Ops": [ "productb-user", "productb-ops" ]
   }
   

I'm still thinking about this.

[nonspecialist]

continuing from above ...

(2) is clearly Wrong, because it requires sshephalopod to be able to maintain a map of all currently-known users that might log in. This breaks Single Source of Truth, so I'm not doing that.

(1) would be lovely to have, but in practice requires a large amount of probably very custom configuration in both the back-end authentication store (whether it be Active Directory, LDAP, or whatever) and the Identity Provider (ADFS, Shibboleth, Okta, etc) -- and that config is unlikely to be portable from one implementation to another.

(3) therefore wins by default. It's not an awful way of doing it, and now that we have external config implemented (see Issue #3 ) -- it's easy to update on the fly.

[mdub]

(3) Seems sensible to me.