This page has moved to https://github.com/GENI-NSF/geni-docs/blob/master/GeniAbacCredentials.adoc
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
- The
head
element must include akeyid
containing the SHA1 hash of the public key contained in the x509 certificate that signed this credential (and which is attached in the signature).
- 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.
- A
- 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. Alinking_role
element must not appear without arole
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.
This credential is only valid if:
- It validates against the schema (attached)
- The XML signature is valid per the XML-DSig standard
- The signing certificate is valid and trusted (see the GENI certificates page).
- The expiration date has not passed
- The
keyid
of thehead
matches the credential signer (the SHA1 hash of the public key in the signing certificate)
Further details on verification can be found on the GENI SFA credential page.
Note that these credentials may not be delegated (in contrast to GENI SFA credentials).
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 <-.
<signed-credential> <credential xml:id="ref0"> <type>abac</type> <version>1.0</version> <expires>2033-05-12T18:33:02Z</expires> <rt0>f98bec95a3ade2968378bd9ef77104e8f9031ec4.friendly<-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)
-
rt0.xsd (945 bytes) - added by 11 years ago.
XSD additions for RT0
Download all attachments as: .zip