no filters on mappings

6 posts / 0 new
Last post
no filters on mappings

Michael Shapiro reminds me that in the X.509 grid-mapfile world, we have some filters in place to meet IGTF policies. Specifically:

  • There are no "Community User" mappings created by default.
  • Only mappings for "vetted" users on active allocations are included.

These filters are in place because IGTF does not allow us to issue user certificates to non-persons like "Community Users" and does not allow us to issue certificates to unvetted users.

I think in the OAuth world, we can free ourselves from these constraints, and we should deliver a tool that includes all the username mappings for the resource. Let the resource provider decide when to disable accounts when allocations end, and let the OAuth tokens specify the level of identity vetting via standard OAuth methods like authentication context reference (acr).

The design document needs to be more explicit on this topic.

Delivery Effort Stage: 

I think that the Authentication Context Class Reference (acr) will be essential for this to work and be acceptable to SPs - we must be able to apply rules to satisfy policies and authentication assurance regulations associated with access to systems and data. This must include a reliable indicator of the vector by which a user authenticated her/himself to Globus Auth, the veracity of the authentication method (third-party MFA?), and the validity period for the authentication session.

Agreed. But we need to be careful not to toss all of this into the mapfile generation process.  The mapfile probably isn't the place to put authorization policies like those, which are tied to specific authentication events. The primary purpose of the mapfile is to map XSEDE identities to local resource identities. You're right that it plays a role in authorization, because if a matching entry isn't present, authorization will fail.  But even if there IS a matching entry, that doesn't mean that authorization should succeed!  It just means that IF authorization succeeds, we know which local account to map the user to.

I'm pretty sure we'll want the ACR check to be in the PAM authorization module that's used by the service, whether the service is a Globus Connect Server (for data access), SSH with Globus Auth (for login access), or something else entirely. And not just an ACR check, but--as you point out--also the IDP used and the timing of the specific authentication event.  These requirements should be encoded in the configuration for the OIDC PAM authorization module and evaluated for every connection attempt.

Would you agree that it seems unlikely that XSEDE will allow logins to be authorized unless the following criteria are met?

  1. The user must authenticate with the XSEDE IdP.
  2. MFA must be used. (Since we're only accepting the XSEDE IDP, the MFA will be Duo.)
  3. The authentication must have been no more than X minutes prior to the login attempt.
  4. The authentication must have been in the same "session," meaning the same application and device.
  5. The mapfile has an entry with the given XSEDE identity mapped to a specific local resource identity.

Assuming the above is probably what we're headed for, I'm reasonably certain that the PAM module used in SSH with Globus Auth will support this policy.  I know that Globus Connect Server also supports that policy when used on a high-assurance server. (The standard GCS 5.x doesn't go that far.)

Right, keep the mapfile simple. We do, however, need means (config files of some kind) to specify policies associated with identities mentioned in the mapfile.

Would it be helpful for the key value in the mapfile to indicate the authorization service from which the token is issued?, e.g.,

globusauthXX1:// janespscbridgesusername
globusauthYY2:// janesPSCuseraccountforYY2
otherOIDCauthz:// janesotherPSCaccount

Regarding criteria, we may also want to know things like:

+ how long the authentication token is valid for (i.e., always require "expires_in" to be defined)
+ whether the token has been revoked by the authorization server in the time since the token was issued
+ means to validate the authorization server
+ how to enforce policies associated with refreshing/refreshed tokens
+ how to specify and interpret token scope values

- Derek

I have a request into Globus (Jason Alt) to syslog the authorization through the PAM module (and I sent him sample c code for syslog :P ).  Currently, the PAM logging for their module is limited and logs everything the same (something like keyboardauthentication ).  I would like it to show which Globus ID was matched.  I have 5 GO ids so far...


I don't understand what this has to do with the mapfile generation?

Log in to post comments