Expose and document all VOMS attributes as Nginx embedded variables

Currently vo name and fqans are supported. It should also support:

• VO uri
• Generic attributes
• Time validity information (notBefore, notAfter)

mentioned in issue #5 (closed)

created branch 4-expose-and-document-all-voms-attributes-as-nginx-embedded-variables

At the moment the module has support for user name (DN) and FQANS.

Looking at struct voms, the list of (interesting) attributes is:

• user DN
• user CA
• server DN
• server CA
• VO name
• VOMS server URI
• not-before
• not-after
• generic attributes
• FQANS
• serial number

Generic attributes are represented by the following data structures:

struct attribute {
  std::string name;      /*!< attribute's group */
  std::string qualifier; /*!< attribute's qualifier */
  std::string value;     /*!< attribute's value */
};

struct attributelist {
  std::string grantor;               /*!< Who granted these attributes. */
  std::vector<attribute> attributes; /*!< The attributes themselves.    */
};

voms::GetAttributes() returns a std::vector<attributelist> What kind of string representation can be used for a std::vector<attributelist>?

The string representation used currently in voms-proxy-info is:

name=value (qualifier)

For the headers set by the module I would go for a representation that is more easily parsable, something like:

n=attr_name v=base64(attr_value) q=qualifier

The attribute value is base64 encoded to avoid issues with commas etc...

So this attribute:

message=giaco, basta con sto c++ (test)

is encoded as

n=message v=Z2lhY28sYmFzdGEgY29uIHN0byBjKysK q=test

That's the representation of a single attribute. Then you have attributelist and std::vector<attributelist>.

Output from discussion:

• we assume that the std::vector<attributelist> has at most one element
• we ignore grantor, which should be equal to other info already available

For the encoding the alternatives are:

• base64 encoding
• base64url encoding
• percent encoding (a.k.a. url-encoding)

Percent encoding has the advantage to be almost readable; base64(url) encoding is more uniform and widely used to represent binary data. base64url uses characters more friendly to URLs and filenames.

Your choice: any of the three is fine for me, with slight preference for base64url encoding

closed