Infrastructure

As per requested by Dave Vieglais, investigate the structure of a DataONE authentication token for use by DataONE services during the verification of a user's credential. A discussion regarding a proposed token structure (that being prototype for the LTER Network Information System) occurred during the 1 December CCIT call focused on whether the X.509 certificate was adequate for replacing a token? Missing from the certificate, however, are any attributes that define a user's group affiliation(s). Jim Basney was asked whether additional attributes may be injected into the certificate just prior to the CILogon digital signing of the certificate - his response follows:

The core question is attribute push versus pull, i.e., whether you
inject user attributes into the token, and then push the token with
those attributes around, or you just have an identifier in the token and
pull (query for) attributes from the appropriate attribute store on
demand when/where they're needed. In the GridShib project we did a lot
of work with both approaches, and every time we did attribute push, we
later regretted it.

The problems with attribute push are knowing in advance what attributes
to put in the token and where to get them from and whether they're still
current. It's difficult for CILogon or any general-purpose identity
provider to gather the VO-specific (i.e., DataONE-specific) attributes
to put in the token. CILogon would need to figure out that the user
needs DataONE attributes (and not OOI attributes or iPlant attributes or
...) and then figure out if there are any attributes specific to the
DataONE Member Node that the user wants to access versus DataONE-general
attributes. The result is CILogon ends up asking the user for
information and things end up breaking mysteriously because CILogon made
a bad decision about which attributes to put in. For example, a
researcher is involved in both DataONE and iPlant, and CILogon made the
mistake of putting in DataONE attributes when the researcher wanted to
do iPlant things.

In contrast, the DataONE Member Node knows what the user is trying to do
and knows what attributes it needs (from where) to make the local
authorization decision. Maybe it wants to combine attributes from the
central DataONE group service plus its local LDAP in case the user has
some local privilege assignments. Therefore, the Member Node is in a
much better position to pull in the attributes than CILogon is.

So... the short answer is that it's possible for CILogon to inject
attributes into the certificate. We've got the code to do it. I just
think we shouldn't, based on past experience.... Of course I'm willing
to keep an open mind and discuss further...

At issue, I believe, is whether the content in a certificate would become stale if it were to have an extended lifetime; this possibility, and its user dissatisfaction implications (where the user would be required to regenerate a new certificate with up-to-date information) would have to be weighed against any performance reduction if all DataONE services would be required to dynamically query a "group service" for affiliation information of a user. It appears, however, that CILogon would accomodate DataONE's needs as necessary.

Completed by deciding to use SAML2 Assertions as the structure for session descriptions. These contain user identity, groups, and identity mappings for the session. See the description in the Authentication sections of the Architecture documents for details.