Initial questions

[Shaky212]

Below is a sketch of the projects/repos within geteduroam

As can be seen from the above, the letswifi-admin will immediately request data from the database. In addition, there will also be write actions (e.g. revoking users).

To ask:

Login

1. How do administrators log in? Via Surf or will the administrator's credentials be included in the letswifi database?

Manage log table (realm_signing_log)

1. Which columns can be searched to find a user in the realm_signing_log:

   • requester
   • sub
   • realm (?)
   • ca_sub (?)
   • other columns…?

2. What actions can be done on a user:

   • revoke (set from NULL to current date, which blocks)
   • other …

Adjust configuration

1. Does this concern the configuration per organization?
2. Which settings are desired per organization?
   • Certificate validity period (used in determining the realm_signing_log.expires?);
   • Which attributes get which username domain prefix from SAML (realm in RADIUS slang). Please explain;
   • Who else is an administrator within the institution (via eduPersonalPrincipalName)? Please explain.

Access Control List (ACL)

As it has been proposed to introduce different levels:

1. global admin
2. admin on a realm (and subrealms)
3. further delegation)

This approach an quickly become complex. The roles and rights must also be manageable in themselves. Perhaps limit the roles to 1. and 2. in the first instance?

Other questions

1. Is it possible to get an export to import the database.

[pauldekkers]

I'll try to answer some/come up with some ideas:

Login:

1. The admins will log in via SAML authentication (SimpleSAMLphp, optionally it could be OIDC) and that will very likely authenticate to either SURFconext, eduGAIN or something else that is local.

SURFconext cannot be assumed ;-) (and thus also no SAB roles; we may add the ability to use it, by entitlement, to bootstrap admin roles, but that has no priority: currently I'd say that global admins (as per ACL 1) assign admins for a realm.)

I think we need a per-instance unique identifier for admin usernames, and for instance default this (by env?) to the eduPersonPrincipalName (allow env to set it to something else if necessary). A possibility exists that we'd have a different attribute for a different organization (like in NL we have both users with nlEduPersonRealId and eduPersonPrincipalName as unique identifiers; but maybe we should resolve that with a rewrite in SimpleSAMLphp for those cases).

It would be nice if an admin (by ePPN) could administer multiple organizations, and have some organization switch. This would also allow to have NRO admins. I'm going to follow up on your ACL idea, because we may need a level between 1 and 2. (and may not have a lot of further delegation)

[pauldekkers]

Re ACLs:

"It depends", we may have an installation on campus, administered and used solely by uni IT. We have installations run by NROs (NRENs) for their member institutions/universities, that means you have an organization like SURF operating it for their universities, and I think the level is then 1 and 2.

The most complex case is the global one, where we have global operations, NROs administering their institutions, and institutions managing themselves (or one or more). Perhaps the level of NRO admins and instituion admins can be somewhat the same, but it would be nice if NRO admins could add more organizations themselves. Assuming that an organization is now unique by realm with the database design of the letswifi CA, I think that allows for this idea. (As long as the realm is unique.)

So, I think we can limit ourselves to 1 and 2, but that some 2's have right to see more organizations and/or even create them?

[pauldekkers]

Re Manage log table (realm_signing_log):

1. I think we need to find a user based on sub (certificate subject) and/or requester mostly. The requester will be the users unique identifier, in most cases the eduPersonPrincipalName, sometimes the persistent Name ID (set by the userIdAttribute in the config currently, though it would be nice if this config can be generated from within the database, thus by something set via the letswifi-admin also). The sub will contain the certificate subject, and thus be the username: an example for the database field would be CN=qexxxxdwrqxxxhn2@medewerker.institution.geteduroam.nl but the actual username is thus without the CN= (perhaps that could just as well be removed, but it's the way it currently is - Jorn may have feedback on it).

The realm may be a nice field to filter by also: it's part of the username of course (so I'd assume that if you search medewerker.institution.geteduroam.nl you'd find all people with medewerker). The realm field actually contains institution.geteduroam.nl in this case! So it's a unique key for the organization in a way.

[pauldekkers]

Re Manage log table (realm_signing_log):

2. I'd say that you described the actions well ;-) look up the user details (in the future possibly authentications also) and revoke it by adding a date instead of NULL.

I wonder if there's a scenario where we may see/require bulk action, but that's for later maybe.

[pauldekkers]

Re Adjust configuration:

There's quite a few settings now done in .php configuration files, that would be nicer to have from the database. Some realm based settings are in the database like the realm_vhost (which in most setups I think is actually 1:1 the http domain, but it doesn't need to be) and the realm_trust that pins the realm to one or more CAs, and realm_server_name listing one or more server names for the RADIUS server (these end up in the .eap-config files). The realm_signer table indeed configures the default certificate validity per realm. There is currently no way to alter this based on SAML attributes (yet there is the desire to do so; so this may be overwritten by some kind of "profile", like there is a realm prefix: perhaps the same logic can apply).

I'll give you an example database dump to work with for now, out of band.

Many settings are in letswifi.conf.php, and I think letswifi.conf.simplesaml.php has an extensive example of all options for an organization (realm).

The key is the realm, but they also have the userIdAttribute defining the username we use as requester and to trace the user. We have the authSource to a particular link in SimpleSAMLphp - I don't think this is very dynamic and doesn't need to be configurable, but we may have a selector. (For you idea; at SURF we have one authSource for SURFconext and the other one for Kennisnet, in the international deployment it's all eduGAIN.) ThesamlIdP is a SAML entityID, and there is an ability to authorize based on other attributes by verifyAuthenticatingAuthority and authzAttributeValue has a dictionary for this purpose (to for instance be strict on values of a schacHomeOrganization or nlEduPersonHomeOrganizationId).

There is also the ability to configure userRealmPrefixAttribute, and have a userRealmPrefixValueMap. An example configuration:

                        'someschool.geteduroam.nl' => [
                                'userIdAttribute' => 'nlEduPersonRealId',
                                'authSource' => 'entree',
                                'samlIdp' => 'https://something.for.entity.ID',
                                'verifyAuthenticatingAuthority' => false,
                                'authzAttributeValue' => [ 'nlEduPersonHomeOrganizationId' => 'SOMEID' ],
                                'userRealmPrefixAttribute' => 'eduPersonAffiliation',
                                'userRealmPrefixValueMap' => [
                                        'student' => 'leerling',
                                        'employee' => 'medewerker',
                                ],
                                'idpList' => [
                                        'SAML-IDP-SCOPING',
                                ],
                        ],

(I picked a more complex example because it's from Kennisnet with different attribute values you're used to. This may happen with local installations also.)

I think if most of this is in the database, it can easily be included, like with 'realm.auth' => (require __DIR__ . DIRECTORY_SEPARATOR . 'letswifi-database-realms.php') from the existing portal/ca.

There is currently no knowledge in the database of an institution administrator (by userID) at all.

[jornane]

How do administrators log in? Via Surf or will the administrator's credentials be included in the letswifi database?

It'd be nice if both are supported, set up via a config file. However, local login might be without database with just a static set password?

Which columns can be searched to find a user in the realm_signing_log:

Search should be scoped by realm I think, so pick a realm and then search within the realm.

Search then on:

• requester: yes, this is the user
• sub: yes, this is the name of the certificate ("pseudo-credential")
• realm (yes, scoped)
• ~ca_sub~ (doesn't need to be searchable)

What actions can be done on a user:

• Revoke based on "subject" (pseudo-credential, one result) or "requester" (user, multiple results)
• Later, when we have log integration with RADIUS server, view RADIUS Access-Accepts for this user

Adjust configuration

Does this concern the configuration per organization?

We have no concept of organization yet, but yes; an organization has multiple realms, so we need an extension to the database for this. letswifi-portal doesn't care about the organizations, but the admin panel does.

Which settings are desired per organization?

• Certificate validity period

Yes; realm_signer.default_validity_days

• Which attributes get which username domain prefix from SAML (realm in RADIUS slang). Please explain;

This is currently set in the config file, but we need this in the database. I think the best way to do this is simply an extra "auth_config" TEXT JSON column in the realm table

• Who else is an administrator within the institution (via eduPersonalPrincipalName)? Please explain.

This must relate to the login for the admin panel, so it should be in a separate to be created table

Access Control List (ACL)

As it has been proposed to introduce different levels:

• global admin
• admin on a realm (and subrealms)
• further delegation)

This approach an quickly become complex. The roles and rights must also be manageable in themselves. Perhaps limit the roles to 1. and 2. in the first instance?

Sounds good.

Other questions

• Is it possible to get an export to import the database.

I don't understand the question?

Other thing: for each realm we also need to set SSID and HS20 data, and helpdesk data. This is currently hardcoded, we need to add tables and/or columns for this.