Does not export GSS naming attributes as apache environment variables

[alejandro-perez]

It would be great if the module could export GSS naming attributes (https://tools.ietf.org/html/rfc6680) as apache environment variables.

[spaetow]

I'd like to +1 that! 👍

Alex, perhaps pop your patch (that you did for our module) over for it to be rolled into this module also? :-)

[alejandro-perez]

Sure, hope it helps. Basically, it is the code from gss-server to extract the attributes, and then use the apr_table_set(r->subprocess_env, attribute_name, attribute_value) to make them available. It can be improved, but you should get the idea :).

// export GSS Attributes are environment variables
{
  OM_uint32 major, tmp;
  int name_is_MN;
  gss_OID mech = GSS_C_NO_OID;
  gss_buffer_set_t attrs = GSS_C_NO_BUFFER_SET;
  unsigned int i;

  major = gss_inquire_name(&tmp, client_name, &name_is_MN, &mech, &attrs);
  if (GSS_ERROR(major)) {
    apr_table_set(r->subprocess_env, "GSS-ERROR", "ERROR");
  }
  else{
    if (attrs != GSS_C_NO_BUFFER_SET) {
      for (i = 0; i < attrs->count; i++){
        gss_buffer_desc value;
        gss_buffer_desc display_value;
        int authenticated = 0;
        int complete = 0;
        int more = -1;
        char *attribute_name = NULL, *attribute_value = NULL;
        gss_buffer_t attribute = &attrs->elements[i];

        value.value = NULL;
        display_value.value = NULL;

        major = gss_get_name_attribute(&tmp, client_name, attribute, &authenticated,
                                       &complete, &value, &display_value,
                                       &more);
        if (GSS_ERROR(major)) {
            break;
        }
        attribute_name = malloc(attribute->length + 1);
        snprintf(attribute_name, attribute->length + 1, "%.*s", (int)attribute->length, (char *)attribute->value);

        attribute_value = malloc(display_value.length + 1);
        snprintf(attribute_value, display_value.length + 1, "%.*s", (int)display_value.length, (char *)display_value.value);
        apr_table_set(r->subprocess_env, attribute_name, attribute_value);

        free(attribute_name);
        free(attribute_value);
        gss_release_buffer(&tmp, &value);
        gss_release_buffer(&tmp, &display_value);

      }
    }
    else{
        apr_table_set(r->subprocess_env, "GSS-ERROR", "No attributes");
    }

  }

  gss_release_oid(&tmp, &mech);
  gss_release_buffer_set(&tmp, &attrs);

}  

[simo5]

This is a great idea, but perhaps we need a way to enable/disable it and also choose which attributes ?
For example if there is a MS-PAC attached to a ticket, then processing may take quite some time if the code starts unwinding all its content (it doesn't right now but I plan to add support in the future).

Do you have specific attributes you are looking for, right now ?

[spaetow]

Enabling/disabling attribute release is a good idea, yes... Perhaps:

GssapiAttributeRelease On | Off

As for the attributes to release, perhaps a simple list:

GssapiReleasedAttributes attribute1,attribute2,attribute3,attribute4

I don't think commas are allowed in attribute names (but colons and underscores are), so that may need to be taken into account? The attributes that are currently processed by Alejandro's stuff are usually string- or number-based. :-)

[alejandro-perez]

I don't think it is a good idea to have an exhaustive list of attributes. For instance, I'm interested on federated attributes (RFC 7056), and they can be kind of impredictable.I'd like to see all the federated attributes, whichever their name is.
Note that I'm not asking for any hard processing, just to pass them in the same way as gss-server does (kind of raw information). The web application will process them.

An intermediate option would be using wildchard. As RFC 7056 assumes prefixes, I might want to establish that I'm interested in anything matching "urn:ietf:params:gss:federated-saml-attribute*"

[simo5]

Uhm interested in knowing which mechanism returns that, is it gss-eap or similar ?

[alejandro-perez]

you got it :)

[alejandro-perez]

Basically, we are using it within OPenStack, and we need the federated attributes to perform the mapping from a federated user to a Group. REMOTE_USER is just not enough :)

[spaetow]

I like the wildcard idea... but filtering attributes might be useful :-)

[simo5]

The main issue I see is maintaining these attributes on each invocation when using the cookie as it may explode the cookie size.

Do you care for losing them if when GssapiUseSessions is turned On ?
You may not care for using it with gss-eap, or maybe you are ok with huge cookies...
The other option is to develop a cache and reference it via session, which would be a bigger job.

[simo5]

Btw can you provide an example of attribute names and values ?
I was thinking of naming them with GSS_NA_ as prefix and then the actual name, and the raw value as value, however there is also the problem that name:value is not conveying all the information, for example it does not convey the "authenticated" bit.

[spaetow]

Raw copy-paste from a web run (using phpInfo()):
_SERVER["urn:ietf:params:gss:radius-attribute_79"] no value
_SERVER["urn:ietf:params:gss:radius-attribute_80"] no value
_SERVER["urn:ietf:params:gss:radius-attribute_26_25622_135"] no value
_SERVER["urn:ietf:params:gss:radius-attribute_1"] bob
_SERVER["urn:ietf:params:gss:federated-saml-assertion"] <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="foo" IssueInstant="2011-03-19T08:30:00Z" Version="2.0"><saml:Issuer>urn:mace:incommon:osu.edu</saml:Issuer><saml:AttributeStatement><saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue>member@example.com</saml:AttributeValue></saml:Attribute><saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue>moonshot</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion>
_SERVER["urn:ietf:params:gss:federated-saml-attribute_urn:oasis:names:tc:SAML:2_0:attrname-format:uri_urn:oid:1_3_6_1_4_1_5923_1_1_1_6"] member@example.com
_SERVER["urn:ietf:params:gss:federated-saml-attribute_urn:oasis:names:tc:SAML:2_0:attrname-format:uri_urn:oid:1_3_6_1_4_1_5923_1_1_1_7"] moonshot
_SERVER["entitlement"] moonshot
_SERVER["HTTP_HOST"] debian7x64.localdomain
_SERVER["REMOTE_USER"] bob
_SERVER["AUTH_TYPE"] Negotiate
_SERVER["PHP_AUTH_USER"] bob
:
:

[iboukris]

Perhaps we could start by exposing the whole client_name (gss_name_t) as environment variable GSS_NAME for other modules to inquire (perhaps exported with gss_export_name).

For mechanism that require GssapiConnectionBound we'll probably have to attach it to the connection though, to span as the authentication.

[alejandro-perez]

1. I don't really care of losing them. What I want is to pass them to the application, so it will take care thereafter.
2. You are right in that having (attribute, value) pairs does not contain all the information. I guess the prefix you are mentioning might be a good idea (GSS_NA_ = not autehnticated, GSS_A_ = authenticated). But...(see next bullet)
3. Stefan's example might be confusing in a point. Although some names appear to have the "_" char, it is something that is being done by PHP info function. The actual name of the attributes includes spaces. For instance, it should actually be "urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2_0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.6". Indeed, even if PHP shouws the name that way in our module, applications MUST use the space, or the attribute is not found. This might make it more confusing. E.g "GSS_A_urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2_0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.6"

[simo5]

given names are namespaced already we can avoid the prefix
we'll lose information on whether they are authenticated, for that we may have the option of returning 2 additional env vars:
GSS_NA_ATTRIBUTES and GSS_A_ATTRIBUTES which are lists of names of attributes
the advantage of having these lists is that you have a handle to easily find attributes withouth having to scan the whole environment array fort potential matches
it also allow you to stack different apache modules that may retuirn similar env vars and still be sure to match only the ones that have been returned by mod_auth_gssapi (unless other modules decide to overwrite stuff.

Are spaces in env var names legal ? Otherwise we'll also need to replace spaces with '_' like PHP does.