wiki:TIEDABACCredential

Version 6 (modified by Aaron Helsinger, 10 years ago) (diff)

--

GENI ABAC Credentials

GENI ABAC credentials are used to store or communicate ABAC statements directly. This format describes a format for passing RT0 credentials, which can express the statements described here. In GENI, credentials are typically passed around in a struct that identifies the type and version of the credential. For GENI API purposes, this page describes credentials of the type geni_abac and version 1.

ABAC credentials are, like GENI SFA privilege credentials, XML documents signed using XML dsig. The contents of an ABAC credential are contained in a signed-credential element. The ABAC data is in a credential element and signature information in the signatures element. The signatures element holds XML digital signature information, signing the credential element.

This page describes both the initial, deprecated version 1.0 abac credential and the new version 1.1 credential that more closely follows the GENI SFA credential format. (Note that both are known within GENI as type geni_abac version 1.) Version 1.0 (never deployed) made changes to the credential element itself, while version 1.1 uses the type field to add an abac element parallel to the privilege element. In addition, version 1.1 encodes the ABAC statement inside XML clauses so other XML tools can understand it should they need to. In addition, the principal names - SHA-1 public key hashes - are annotated with human-readable names that can be used by libabac or third party applications.

Version 1.1 Credentials

Intuitively, Version 1.1 credentials modify the GENI SFA credentials by making a type of "abac" valid in the type element, and adding an abac element parallel to the privilege, ticket, and capabilities elements. The abac field includes the version of the ABAC encoding (1.1) and the ABAC statement encoded in XML.

  • The version element is 2 non-negative integers separated by a period. No spaces. A major and minor version number. This section describes version 1.1

Some fields of the GENI SFA credential make little sense for the ABAC credential. The libabac implementation produces empty elements for these fields and ignores their presence when parsed:

  • serial
  • owner_gid
  • owner_urn (not generated)
  • target_gid
  • target_urn (not generated)
  • uuid

The expires element specifies the expiration of the credential. It is in the same format as the GENI privilege credential (ISO 8601 with UTC assumed if no timezone is specified, RFC 3339 format preferred).

When the type element is "abac", an abac element must be present. The abac field contains a single rt0 element with one head element and one or more tail elements. Each head or tail element contains

  • An ABACprincipal element. This contains
    • A keyid element that contains the SHA-1 hash of the principal's public key (from the principal's X509 certificate)
    • An optional mnemonic element that contains a human-readable name of the principal, used in presenting the contents to people (E.G. something from the DN or SubjectAltName of the principal's certificate; In GENI, typically the URN.
  • An optional role element. This contains a string, the last clause in the RT0 term.
  • An optional linking_role element. This contains a string, the middle clause in an RT0 term. A linking_role element must not appear without a role element.

The RT0 term "e80dc149dfdfaf18e2ecd230a2b214d731d8910f.partner.experiment_create" looks like this in the XML representation:

<ABACprincipal>
 <keyid>e80dc149dfdfaf18e2ecd230a2b214d731d8910f</keyid>
</ABACprincipal>
<role>experiment_create</role>
<linking_role>partner</linking_role>

If the keyid "e80dc149dfdfaf18e2ecd230a2b214d731d8910f" refers to a principal named "Acme" then the element might be annotated with a mnemonic element:

<ABACprincipal>
 <keyid>e80dc149dfdfaf18e2ecd230a2b214d731d8910f</keyid>
 <mnemonic>Acme</mnemonic>
</ABACprincipal>
<role>experiment_create</role>
<linking_role>partner</linking_role>

A full Version 1.1 credential encoding the RT0 statement Acme.experiment_create <- Acme.partner.experiment_create (with signature contents trimmed) looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<signed-credential>
 <credential xml:id="ref0">
  <serial/>
  <owner_gid/>
  <target_gid/>
  <uuid/>
  <type>abac</type>
  <expires>2014-06-14T22:41:36Z</expires>
  <abac>
   <rt0>
    <version>1.1</version>
    <head>
     <ABACprincipal>
      <keyid>e80dc149dfdfaf18e2ecd230a2b214d731d8910f</keyid>
      <mnemonic>Acme</mnemonic>
     </ABACprincipal>
     <role>experiment_create</role>
    </head>
    <tail>
     <ABACprincipal>
      <keyid>e80dc149dfdfaf18e2ecd230a2b214d731d8910f</keyid>
      <mnemonic>Acme</mnemonic>
     </ABACprincipal>
     <role>experiment_create</role>
     <linking_role>partner</linking_role>
    </tail>
   </rt0>
  </abac>
 </credential>
 <signatures>
 ...
 </signatures>
</signed-credential>

Multiple tail elements are treated an intersection element - all the tails must hold to assign the head.

The xsd additions to the GENIAPI credential XSD are attached to this page. They encode the rt0 element inside the abac element. Minor additions need to be made to add the abac element as a choice.

Version 1.0 Credentials (deprecated)

The credential element contains:

  • A type element whose content is "abac" this differentiates it from a GENI privilege credential
  • A version element whose content is 2 non-negative integers separated by a period. No spaces. A major and minor version number. This page describes version 1.0
  • An expires element whose content defines the last time the credential is valid. It is in the same format as the GENI privilege credential.
  • An rt0 element that includes an encoding of the RT0 rule. All take the form Principal.Attr <- RHS according to the following rules
    • Principals are encoded by their Subject Key Identifier - a SHA1 hash of their public key data. These are shown in italics below.
    • Attributes are space-free strings containing alpha-numeric data and underscores.
    • An assignment of an attribute to a principal is of the form issuer.attr <- principal
    • An assignment of an attribute to a set of principals that have an attribute is of the form issuer.role1 <- principal.role2
    • An assignment of an attribute to a set of principals assigned a given attribute by a principal with a given linking attribute has the form issuer.role1 <- principal.linking_attribute.role2. See here for examples of this type of role.
    • The right side of the assignment (RHS) may be a conjunction of the various RHS types above, e.g., issuer.role0 <- principal1.role1 & principal2.role2

An example abac credential (formatted for display which may invalidate the signature) follows. Note that the <- in the <rt0> element has been escaped as &lt;-.

<signed-credential>
 <credential xml:id="ref0">
  <type>abac</type>
  <version>1.0</version>
  <expires>2033-05-12T18:33:02Z</expires>
  <rt0>f98bec95a3ade2968378bd9ef77104e8f9031ec4.friendly&lt;-3f2531dd349d831a0217907b03f309ebb81a447e</rt0>
 </credential>
 <signatures>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
   <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <Reference URI="#ref0">
     <Transforms>
      <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     </Transforms>
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <DigestValue>DEGT6ENGnJDxSK/KQ98B2lKGn2M=</DigestValue>
    </Reference>
   </SignedInfo>
   <SignatureValue>tDFuWoUimexrKlvnh6ie4fL7EX3NTsOSrry9X3szC9GZwNdxOHaDplwopFD/4/vE
Uv+e78OBWybRQKBKse0tuIc7mRQTUflwAKJHiIUbbffSJ/IGxxnKn4Oz559ouZej
cIv6ssSN5fNojSbwlYPGvCmtjOP+/kVE8enKyBqS++nbySUDM0yG28rF57kvRic0
mq0zWF1cKBgPNgH35jeGFlpsDqXIcESLM3z6RUtmvhNm/ynbbhqL0mOy7Os8hDqV
jKPlkTb5916lzMpYVuPeVmU2RX/OuqZET7cLo5LZ5P3V5X7XjSXU61rcr51a6HTO
L6eCu7/8eVcxsNVlytwepg==</SignatureValue>
   <KeyInfo>
    <KeyValue>
     <RSAKeyValue>
      <Modulus>
2r8ogNUkqz8FezxQgvDq29uMuDtzPIV5uTWlM5IVy0x1aKWREA+wG1Xe3b6jDzhD
D4BDQQkgUYIWTq+lnhsDqz60yKy+DZ/TzSU3kLbJAcXwBEJ7E6YkfOCGK0/D1Bzq
qrD4Jeq1LlkRplE3iwx0eN6CnrQzrD7WlntRP/gf6NKDDQYJBUvS/+boE0IRFFIG
NQem6CUlITFYnIh7bbcNqw8uJcupkLbUN+jg9oWu6+HXRGmUEBC2OCi+5fApDD7e
jyaBs/dTBOTgqVgUv/1ghf+eQrhXRiaug6Beh3U/IJsNjxIdYm01W/ekOgyC3hGz
XdTm56HwZGw55Z7nVsi+Mw==
</Modulus>
      <Exponent>
AQAB
</Exponent>
     </RSAKeyValue>
    </KeyValue>
    <X509Data>
     <X509Certificate>MIIC/TCCAeWgAwIBAgIIZYdpzvz3KRUwDQYJKoZIhvcNAQEFBQAwDDEKMAgGA1UE
AxMBQTAeFw0xMzA1MTcxODMzMDFaFw0zMzA1MTIxODMzMDFaMAwxCjAIBgNVBAMT
AUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDavyiA1SSrPwV7PFCC
8Orb24y4O3M8hXm5NaUzkhXLTHVopZEQD7AbVd7dvqMPOEMPgENBCSBRghZOr6We
GwOrPrTIrL4Nn9PNJTeQtskBxfAEQnsTpiR84IYrT8PUHOqqsPgl6rUuWRGmUTeL
DHR43oKetDOsPtaWe1E/+B/o0oMNBgkFS9L/5ugTQhEUUgY1B6boJSUhMViciHtt
tw2rDy4ly6mQttQ36OD2ha7r4ddEaZQQELY4KL7l8CkMPt6PJoGz91ME5OCpWBS/
/WCF/55CuFdGJq6DoF6HdT8gmw2PEh1ibTVb96Q6DILeEbNd1ObnofBkbDnlnudW
yL4zAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBT5i+yVo63iloN4vZ73cQTo+QMexDAfBgNVHSMEGDAWgBT5i+yVo63i
loN4vZ73cQTo+QMexDANBgkqhkiG9w0BAQUFAAOCAQEAo68/jwfCJvWzYaSo7c5D
li9EJHbeLAheLAilURoh0OwmScNIbrlDh4DMBrNarY35t3tIHxS/tsHv52Haup67
coi/h4GvWNeeMxvciWfcAqY88nPG/Xz0BjxlpCB52MsN2sR6Q/WIyfmFOl6ixdV1
X4XGKnEpKZz3bLAL2BWyzXHY7gPRI/hPk5x073iblexlPwKW8m1htVGmmboEq6YF
7OrPsAYH1297ST/s/G0AvbTJv7eCmbWHnjgW75t1X0Weu5oO8b2c09N03lHuSSdh
1wdsfPvtNCe3yslkPJQG05Exisv+U7H4QpwgEKz2ZFfRTFpKjk82mwFthdPQF32E
jw==</X509Certificate>
     <X509SubjectName>CN=A</X509SubjectName>
     <X509IssuerSerial>
      <X509IssuerName>CN=A</X509IssuerName>
      <X509SerialNumber>7315932457414895893</X509SerialNumber>
     </X509IssuerSerial>
    </X509Data>
   </KeyInfo>
  </Signature>
 </signatures>
</signed-credential>

Attachments (1)

Download all attachments as: .zip