PKI Policy defines the trusted issuer certificates Certificate Authority certificates (trust anchors) and CRL/OSCP OCSP endpoints used when validating certificates or certificate chains and attributes generated from subject and issuer certificates.
The user's certificate is defined to be included in a SAML Assertion or OpenID Connect id_token by defining the Subject element's KeyInfoConfirmationData attribute as true. User's certificate is used by SSO to write the audit log entry “certificate received”.
...
PKI Policy XML configuration file
An example PKI policy XML configuration file is shown below.
...
language | xml |
---|
...
On this page described:
Table of Contents | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
PKI Policy XML configuration file
An example PKI policy XML configuration file is shown below.
|
Trusted issuers Trust anchors are defined in the Trust elements enclosed in a PKI element. The corresponding CRL distribution point is defined in the crl attribute. Other trusted issuers may be added by defining a new Trust element for each trusted issuer.
In addition to certificate path validation tasks, this configuration also defines the contents of the SAML Assertion The subject certificate is defined to be included in a SubjectConfirmation of SAML Assertion by defining the Subject element's KeyInfoConfirmationData attribute as true. The subject certificate is used by SSO to write the audit log entry “certificate received”.
Attributes to be sent to SSO as SAML Assertion attributes and OpenID Connect id_token . For example, the user certificate may be included, specific attributes may be extracted from the certificate and relayed back to service provider, a fingerprint of the certificate may be computed with specified message digest algorithm, and several normalization schemes may be applied for extracted attributes.
The structure and data types of the configuration document are described in the following schema.
Schema Explanation
The <Policy/> element
...
claims are defined in the Attributes element. The name of the attribute is defined in the name attribute of the Add element. The content of the attribute is defined in the enclosed elements. In this example:
The attribute
subject.fingerprint
is defined as a SHA-1 digest (fingerprint) of the subject certificate.The attribute
subject.dn
is defined as the distinguished name of the subject certificate.The attribute
issuer.dn
is defined as the distinguished name of the issuer certificate.The attribute
subject.name
is defined to be concatenated from attribute OID 2.5.4.4 (surname), 
(a space character) and attribute OID 2.5.4.42 (givenName).
The structure and data types of the configuration document are described in the following schema.
Schema Explanation
The <Policy/> element
|
The policy element defines three required child elements: PKI, Subject and Attributes.
The <PKI/> element
|
The PKI element encapsulates <Trust/> definitions. At least one certificate authority (CA) must be configured.
The <Trust /> element
|
The <Trust /> element represents a trusted certificate authority. The element contains a Base64-encoded certificate. The element may also contain crl
attribute defining a CRL URL or ocsp
attribute defining an OCSP URL.
Optionally CRL and OCSP URLs can be defined in a separate element <CRL /> and <OCSP /> as child element for <Trust /> element, and refer to them by their id in crlref
and ocspref
attribute in <Trust /> element.
The <CRL /> and <OCSP /> elements
Code Block | ||
---|---|---|
| ||
<xs:element name="CRL" type="CRLType" /> <xs:element name="OCSP" type="OCSPType" /> <xs:complexType name="CRLType"> <xs:complexContent> <xs:extension base="PropertiesType"> <xs:attribute name="uri" type="xs:anyURI" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="OCSPType"> <xs:complexContent> <xs:extension base="PropertiesType"> <xs:attribute name="uri" type="xs:anyURI" use="required" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="PropertiesType" abstract="true"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="Property" type="PropertyType" /> </xs:sequence> <xs:attribute name="id" type="xs:ID" use="optional" /> </xs:complexType> <xs:complexType name=" |
...
PropertyType"> |
...
<xs: |
...
simpleContent> <xs: |
...
extension |
...
base=" |
...
xs:string"> <xs:attribute name="name" type="xs:string" use="required" /> </xs:extension> </xs:simpleContent> </xs:complexType> |
The policy element defines three required child elements: PKI, Subject and Attributes.
The <PKI/> element
|
The PKI element encapsulates <Trust/> definitions. At least one certificate authority (CA) must be configured.
The <Trust /> element
|
The <Trust /> element represents a trusted certificate authority. The element contains an attribute defining a CRL distribution URL and the element contains a Base64-encoded certificate.<CRL /> and the <OCSP /> element represent a CRL and OCSP endpoint. The endpoint URL is defined in uri
attribute and an optional identifier in id
attribute. The identifier can be used in a <Trust /> element as value for crlref
or ocspref
attribute to refer to <CRL /> or <OCSP /> element, in which case the CRL or OCSP endpoint is used only with that trust anchor. A <CRL /> or <OCSP /> element without id attribute is used with any trust anchor.
PKI Policy supports only one OCSP endpoint per trust anchor.
For example:
Code Block | ||
---|---|---|
| ||
<Trust ocspref="gspersonalsign2g2">MIIEVz...7H34U=</Trust>
<OCSP uri="http://ocsp2.globalsign.com/gspersonalsign2g2" id="gspersonalsign2g2"/> |
The <Subject /> element
|
...
The <Attributes /> element
|
...
The <Add /> element
|
This element is used to add response attributes to the assertion. Each <Add/> element can contain one of the child elements defined in ValueGroup.
|
The <Attribute /> element
|
...
The <Concat /> element
|
The <Concat/> element concatenates information defined by elements of the ValueGroup definition. Each defined element is individually parsed to a textual representation and concatenated with each other to form a single string.
|
The <Digest /> element
|
...
The <Field /> element
|
The <Field /> element allows submitting either the subject's or CAissuer's distinguished name. The names' string representations are, by default, serialized by the JDK X500Principal.toString() –method. The normalization routine can be controlled by defining one of the following values:
Value | Description | |||
---|---|---|---|---|
RFC1779 | http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String) | |||
RFC2253 | http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String) | |||
CANONICAL | http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html#getName(java.lang.String) | |||
altSecurityIdentities | https://msdn.microsoft.com/en-us/library/ms675221(v=vs.85).aspx Code Block | )
|
The <Text /> element
|
...
|
The <Text /> element
|
This element can be used to include arbitrary text in the response attributes or use the text in concatenation with other elements.
The source attribute
Code Block | ||
---|---|---|
| ||
<xs:simpleType name="SourceAttributeType">
<xs:restriction base="xs:string">
<xs:enumeration value="subject" />
<xs:enumeration value="issuer" />
</xs:restriction>
</xs:simpleType> |
The value of source
attribute for Attribute, Field and Digest elements can be either subject
or issuer
. It denotes the source certificate for the element being either the subject certificate, or the issuer of subject certificate.