[JBoss AS 7 Development] - Audit Logging Design Notes
by Kabir Khan
Kabir Khan [https://community.jboss.org/people/kabirkhan] modified the document:
"Audit Logging Design Notes"
To view the document, visit: https://community.jboss.org/docs/DOC-18812
--------------------------------------------------------------
Design notes for work on https://issues.jboss.org/browse/WFLY-456 (formerly https://issues.jboss.org/browse/AS7-444 https://issues.jboss.org/browse/AS7-444).
My current development topic branch for this is https://github.com/kabir/wildfly/tree/WFLY-456-audit-log https://github.com/kabir/wildfly/tree/WFLY-456-audit-log (More current than https://github.com/bstansberry/jboss-as/tree/AS7-444 https://github.com/bstansberry/jboss-as/tree/AS7-444, note that these are personal branches; I make no guarantees not to change its commit history.) This branch is based on work previously done by John Bailey.
Design notes:
1) Processing location in OperationContext
a) when done
b) when decision to not proceed is made in OperationContext
2) Log record format:
a) date
b) read-only?
c) boot?
d) (if boot) version (as string???)
e) rollback?
f) userid (TODO get this somehow)
g) uuid (for domain ops only, to track across processes)
h) isServer?
i) primary (domain or server) model hash
j) if (!isServer) secondary (host) model hash
k) overall hash
l) num operations
m) operations (one at a time)
n) length of a->j (scan from end to last boot during validation; alternative is to write the length first and scan from beginning to last boot)
3) Index record format:
a) overall hash
4) Mgmt operations
a) truncate (back to last boot)
i) don't discard previous; just write under a different file name
b) read log (params -- from (default 0); batch-size (default 20; -1 means all))
c) validate log
d) config changes
5) Validation:
a) compare persisted model hash to current model
b) scan back through log to last config-file-modified boot or version-change boot. We stop at version-change boot to avoid spurious validation problems resulting from changes in model construction across versions
c) recreate by re-running ops
-- validation problems
a) need to verify model hash at each stage -- special controller that ignores all runtime ops
i) problem -- how to recreate domain ops involving remote slaves that don't exist?
ii) problem -- ops with attachments -- attachments won't exist
iii) this "special controller" could end up duplicating a lot of logic just for validation
b) reads and runtime ops cannot be verified against model; it can only be confirmed that their hash is consistent with subsequent hashes in the log. Tamper resistant as modification would require modifying all subsequent log entries, but not tamper proof as this could be done.
6) Domain mode
a) tracking requests from master to slaves
apply a uuid to requests
-- as a header
include uuid in log record
b) detecting host.xml config changes at boot
problem -- can't detect host.xml config changes at boot, as model changes may be due to domain.xml stuff coming from the master
so, independent domain and host logging
but, what about non-model affecting ops? log twice?
c) domain logging on slaves? only if --backup-dc is set? -- no simpler to just log
d) remote-slave-only logging on master?
yes, to maintain a complete record of what was done
7) Non-model-affecting ops
a) re-calculating the model hash for all such ops is too expensive
b) store the hash(es) in the ModelController along with the model
c) provide the hash along with the model to OperationContext
d) when model is updated recalc hashes
8) Config
a) <audit-log> element
b) part of <management> section
c) resource is /core-service=audit-log
d) attributes
i) path (NO -- we need to know the location when first logging, before we have processed ops to set it)
ii) relative-to (NO -- we need to know the location when first logging, before we have processed ops to set it)
iii) log-read-only?
iv) daily-rolling??? (hassle; tempting to defer to later release but it's probably necessary immediately)
9) Other issues
a) disable logging overhead for dev scenarios
i) to disable it during initial boot (until whatever config element that turns it on/off is read) -- maintain log data in memory and only write on last boot op
b) parallel boot handlers should not log
c) fluctuating model hashes
i) if op took the controller lock, that lock ensures proper ordering of model hashes
ii) if op does not take controller lock (reads) earlier model hashes can intermix with later -- validation needs to account for this
*Suggested configuration*
Only relevant elements to audit logging have been included in the following examples.
*+jboss-as-config (i.e. standlone.xml and host.xml)+
*
This defines a set of audit-log-appenders which are referenced by the audit-log element. The appenders are responsible for encryption, if needed. Currently encryption/tamper detection is not a requirement.
<xs:complexType name="domain-managementType">
<xs:annotation>
<xs:documentation>
Domain-wide default configuration settings for the management of standalone servers and a Host Controller.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="security-realms" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="security-realm" type="security-realmType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="outbound-connections" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="ldap" type="ldapType" minOccurs="1" /> <!-- TODO minOccurs only while ldap is only supported connection. -->
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:sequence minOccurs="0">
<xs:element name="audit-log-appenders" type="audit-log-appendersType"/>
<xs:element name="audit-log" type="audit-logType"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="audit-log-appendersType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging appenders.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="simple-appender" type="simple-audit-log-appenderType"/>
<xs:element name="syslog-appender" type="syslog-audit-log-appenderType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="simple-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a simple file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:attribute name="name" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>
The name of the appender
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="path" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>
The path of the audit log.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="relative-to" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="syslog-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a syslog file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:attribute name="name" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>
The name of the appender
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:element name="truststore" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - can we define more than one truststore in java? The normal way seems to be to set -Djavax.net.ssl.trustStore, and there is
already one in authenticationType. It looks like there might be a way, although we would need to extend syslog4j to be able to use SSLContext.
Configuration of a keystore to use to create a trust manager to verify clients.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-certificate-authentication" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - Look into if it is possible to extend syslog4j to use SSLContext.
Configuration of a keystore containing a client certificate and private key, e.g. in PKCS12 format.
</xs:documentation>
</xs:annotation>
</xs:element>
<!-- TODO other configuration, such as retries etc. -->
</xs:sequence>
<xs:attribute name="protocol" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="udp"/>
<xs:enumeration value="tcp"/>
<xs:enumeration value="tls"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="host" default="localhost"/>
<xs:attribute name="port" default="514"/>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration coming from the model controller core.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="appenders" type="audit-log-appenders-refType" minOccurs="0"/>
</xs:choice>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="audit-log-appenders-refType">
<xs:annotation>
<xs:documentation>
References to audit-log-appenders defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1">
<xs:element name="appender" type="audit-log-appender-refType" minOccurs="0"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
+*jboss-as-jmx (jmx subsystem)*+
References the appenders set up in the audit-log-appenders section. This allows for both shared and separate audit logs for core management operations and jmx operations.
<xs:complexType name="subsystem">
<xs:sequence>
<xs:element name="expose-resolved-model" type="resolvedModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="expose-expression-model" type="expressionModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="remoting-connector" type="remotingConnectorRefType" minOccurs="0"/>
<xs:element name="audit-log" type="audit-logType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="appenders" type="audit-log-appenders-refType" minOccurs="0"/>
</xs:choice>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="audit-log-appenders-refType">
<xs:annotation>
<xs:documentation>
References to audit-log-appenders defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1">
<xs:element name="appender" type="audit-log-appender-refType" minOccurs="0"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18812]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 7 months
[JBoss AS 7 Development] - Audit Logging Design Notes
by Kabir Khan
Kabir Khan [https://community.jboss.org/people/kabirkhan] modified the document:
"Audit Logging Design Notes"
To view the document, visit: https://community.jboss.org/docs/DOC-18812
--------------------------------------------------------------
Design notes for work on https://issues.jboss.org/browse/WFLY-456 (formerly https://issues.jboss.org/browse/AS7-444 https://issues.jboss.org/browse/AS7-444).
My current development topic branch for this is https://github.com/kabir/wildfly/tree/WFLY-456-audit-log https://github.com/kabir/wildfly/tree/WFLY-456-audit-log (More current than https://github.com/bstansberry/jboss-as/tree/AS7-444 https://github.com/bstansberry/jboss-as/tree/AS7-444, note that these are personal branches; I make no guarantees not to change its commit history.) This branch is based on work previously done by John Bailey.
Design notes:
1) Processing location in OperationContext
a) when done
b) when decision to not proceed is made in OperationContext
2) Log record format:
a) date
b) read-only?
c) boot?
d) (if boot) version (as string???)
e) rollback?
f) userid (TODO get this somehow)
g) uuid (for domain ops only, to track across processes)
h) isServer?
i) primary (domain or server) model hash
j) if (!isServer) secondary (host) model hash
k) overall hash
l) num operations
m) operations (one at a time)
n) length of a->j (scan from end to last boot during validation; alternative is to write the length first and scan from beginning to last boot)
3) Index record format:
a) overall hash
4) Mgmt operations
a) truncate (back to last boot)
i) don't discard previous; just write under a different file name
b) read log (params -- from (default 0); batch-size (default 20; -1 means all))
c) validate log
d) config changes
5) Validation:
a) compare persisted model hash to current model
b) scan back through log to last config-file-modified boot or version-change boot. We stop at version-change boot to avoid spurious validation problems resulting from changes in model construction across versions
c) recreate by re-running ops
-- validation problems
a) need to verify model hash at each stage -- special controller that ignores all runtime ops
i) problem -- how to recreate domain ops involving remote slaves that don't exist?
ii) problem -- ops with attachments -- attachments won't exist
iii) this "special controller" could end up duplicating a lot of logic just for validation
b) reads and runtime ops cannot be verified against model; it can only be confirmed that their hash is consistent with subsequent hashes in the log. Tamper resistant as modification would require modifying all subsequent log entries, but not tamper proof as this could be done.
6) Domain mode
a) tracking requests from master to slaves
apply a uuid to requests
-- as a header
include uuid in log record
b) detecting host.xml config changes at boot
problem -- can't detect host.xml config changes at boot, as model changes may be due to domain.xml stuff coming from the master
so, independent domain and host logging
but, what about non-model affecting ops? log twice?
c) domain logging on slaves? only if --backup-dc is set? -- no simpler to just log
d) remote-slave-only logging on master?
yes, to maintain a complete record of what was done
7) Non-model-affecting ops
a) re-calculating the model hash for all such ops is too expensive
b) store the hash(es) in the ModelController along with the model
c) provide the hash along with the model to OperationContext
d) when model is updated recalc hashes
8) Config
a) <audit-log> element
b) part of <management> section
c) resource is /core-service=audit-log
d) attributes
i) path (NO -- we need to know the location when first logging, before we have processed ops to set it)
ii) relative-to (NO -- we need to know the location when first logging, before we have processed ops to set it)
iii) log-read-only?
iv) daily-rolling??? (hassle; tempting to defer to later release but it's probably necessary immediately)
9) Other issues
a) disable logging overhead for dev scenarios
i) to disable it during initial boot (until whatever config element that turns it on/off is read) -- maintain log data in memory and only write on last boot op
b) parallel boot handlers should not log
c) fluctuating model hashes
i) if op took the controller lock, that lock ensures proper ordering of model hashes
ii) if op does not take controller lock (reads) earlier model hashes can intermix with later -- validation needs to account for this
*Suggested configuration*
Only relevant elements to audit logging have been included in the following examples.
*+jboss-as-config (i.e. standlone.xml and host.xml)+
*
This defines a set of audit-log-appenders which are referenced by the audit-log element. The appenders are responsible for encryption, if needed. Currently encryption/tamper detection is not a requirement.
<xs:complexType name="audit-log-appendersType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging appenders.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="simple-appender" type="simple-audit-log-appenderType"/>
<xs:element name="syslog-appender" type="syslog-audit-log-appenderType"/>
</xs:all>
</xs:complexType>
<xs:complexType name="simple-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a simple file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:attribute name="name" type="xs:string"" use="required">
<xs:annotation>
<xs:documentation>
The name of the appender
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="path" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>
The path of the audit log.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="relative-to" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="syslog-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a syslog file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:attribute name="name" type="xs:string"" use="required">
<xs:annotation>
<xs:documentation>
The name of the appender
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:element name="truststore" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - can we define more than one truststore in java? The normal way seems to be to set -Djavax.net.ssl.trustStore, and there is
already one in authenticationType. It looks like there might be a way, although we would need to extend syslog4j to be able to use SSLContext.
Configuration of a keystore to use to create a trust manager to verify clients.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-certificate-authentication" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - Look into if it is possible to extend syslog4j to use SSLContext.
Configuration of a keystore containing a client certificate and private key, e.g. in PKCS12 format.
</xs:documentation>
</xs:element>
<!-- TODO other configuration, such as retries etc. -->
</xs:sequence>
<xs:attribute name="protocol" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="udp"/>
<xs:enumeration value="tcp"/>
<xs:enumeration value="tls"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="host" default="localhost"/>
<xs:attribute name="port" default="514"/>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration coming from the model controller core.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0">
<xs:element name="appenders" type="audit-log-appenders-refType" minOccurs="0"/>
</xs:all>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="audit-log-appenders-refType">
<xs:annotation>
<xs:documentation>
References to audit-log-appenders defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1">
<xs:element name="appender" type="audit-log-appender-refType" minOccurs="0"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
+*jboss-as-jmx (jmx subsystem)*+
References the appenders set up in the audit-log-appenders section. This allows for both shared and separate audit logs for core management operations and jmx operations.
<xs:complexType name="subsystem">
<xs:sequence>
<xs:element name="expose-resolved-model" type="resolvedModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="expose-expression-model" type="expressionModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="remoting-connector" type="remotingConnectorRefType" minOccurs="0"/>
<xs:element name="audit-log" type="audit-logType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration.
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0">
<xs:element name="appenders" type="audit-log-appenders-refType" minOccurs="0"/>
</xs:all>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="audit-log-appenders-refType">
<xs:annotation>
<xs:documentation>
References to audit-log-appenders defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="1">
<xs:element name="appender" type="audit-log-appender-refType" minOccurs="0"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18812]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 7 months
[JBoss AS 7 Development] - Audit Logging Design Notes
by Kabir Khan
Kabir Khan [https://community.jboss.org/people/kabirkhan] modified the document:
"Audit Logging Design Notes"
To view the document, visit: https://community.jboss.org/docs/DOC-18812
--------------------------------------------------------------
Design notes for work on https://issues.jboss.org/browse/WFLY-456 (formerly https://issues.jboss.org/browse/AS7-444 https://issues.jboss.org/browse/AS7-444).
My current development topic branch for this is https://github.com/kabir/wildfly/tree/WFLY-456-audit-log https://github.com/kabir/wildfly/tree/WFLY-456-audit-log (More current than https://github.com/bstansberry/jboss-as/tree/AS7-444 https://github.com/bstansberry/jboss-as/tree/AS7-444, note that these are personal branches; I make no guarantees not to change its commit history.) This branch is based on work previously done by John Bailey.
Design notes:
1) Processing location in OperationContext
a) when done
b) when decision to not proceed is made in OperationContext
2) Log record format:
a) date
b) read-only?
c) boot?
d) (if boot) version (as string???)
e) rollback?
f) userid (TODO get this somehow)
g) uuid (for domain ops only, to track across processes)
h) isServer?
i) primary (domain or server) model hash
j) if (!isServer) secondary (host) model hash
k) overall hash
l) num operations
m) operations (one at a time)
n) length of a->j (scan from end to last boot during validation; alternative is to write the length first and scan from beginning to last boot)
3) Index record format:
a) overall hash
4) Mgmt operations
a) truncate (back to last boot)
i) don't discard previous; just write under a different file name
b) read log (params -- from (default 0); batch-size (default 20; -1 means all))
c) validate log
d) config changes
5) Validation:
a) compare persisted model hash to current model
b) scan back through log to last config-file-modified boot or version-change boot. We stop at version-change boot to avoid spurious validation problems resulting from changes in model construction across versions
c) recreate by re-running ops
-- validation problems
a) need to verify model hash at each stage -- special controller that ignores all runtime ops
i) problem -- how to recreate domain ops involving remote slaves that don't exist?
ii) problem -- ops with attachments -- attachments won't exist
iii) this "special controller" could end up duplicating a lot of logic just for validation
b) reads and runtime ops cannot be verified against model; it can only be confirmed that their hash is consistent with subsequent hashes in the log. Tamper resistant as modification would require modifying all subsequent log entries, but not tamper proof as this could be done.
6) Domain mode
a) tracking requests from master to slaves
apply a uuid to requests
-- as a header
include uuid in log record
b) detecting host.xml config changes at boot
problem -- can't detect host.xml config changes at boot, as model changes may be due to domain.xml stuff coming from the master
so, independent domain and host logging
but, what about non-model affecting ops? log twice?
c) domain logging on slaves? only if --backup-dc is set? -- no simpler to just log
d) remote-slave-only logging on master?
yes, to maintain a complete record of what was done
7) Non-model-affecting ops
a) re-calculating the model hash for all such ops is too expensive
b) store the hash(es) in the ModelController along with the model
c) provide the hash along with the model to OperationContext
d) when model is updated recalc hashes
8) Config
a) <audit-log> element
b) part of <management> section
c) resource is /core-service=audit-log
d) attributes
i) path (NO -- we need to know the location when first logging, before we have processed ops to set it)
ii) relative-to (NO -- we need to know the location when first logging, before we have processed ops to set it)
iii) log-read-only?
iv) daily-rolling??? (hassle; tempting to defer to later release but it's probably necessary immediately)
9) Other issues
a) disable logging overhead for dev scenarios
i) to disable it during initial boot (until whatever config element that turns it on/off is read) -- maintain log data in memory and only write on last boot op
b) parallel boot handlers should not log
c) fluctuating model hashes
i) if op took the controller lock, that lock ensures proper ordering of model hashes
ii) if op does not take controller lock (reads) earlier model hashes can intermix with later -- validation needs to account for this
*Suggested configuration*
Only relevant elements to audit logging have been included in the following examples.
*+jboss-as-config (i.e. standlone.xml and host.xml)+
*
This defines a set of audit-log-appenders which are referenced by the audit-log element. The appenders are responsible for encryption, if needed. Currently encryption/tamper detection is not
<xs:complexType name="domain-managementType">
<xs:annotation>
<xs:documentation>
Domain-wide default configuration settings for the management of standalone servers and a Host Controller.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="security-realms" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="security-realm" type="security-realmType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="outbound-connections" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="ldap" type="ldapType" minOccurs="1" /> <!-- TODO minOccurs only while ldap is only supported connection. -->
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:sequence minOccurs="0">
<xs:element name="audit-log-appenders" type="audit-log-appendersType"/>
<xs:element name="audit-log" type="audit-logType"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="audit-log-appendersType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging appenders.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="simple-appender" type="simple-audit-log-appenderType" minOccurs="0"/>
<xs:element name="syslog-appender" type="syslog-audit-log-appenderType" minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="simple-appender" type="audit-log-appender-refType" minOccurs="0">
<xs:annotation>
<xs:documentation>
A reference to an appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="syslog-appender" type="audit-log-appender-refType" minOccurs="0">
<xs:annotation>
<xs:documentation>
A reference to an appender defined in the audit-log-appenders section
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="simple-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a simple file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:attribute name="path" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>
The path of the audit log.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="relative-to" use="optional" type="xs:string">
<xs:annotation>
<xs:documentation>
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="syslog-audit-log-appenderType">
<xs:annotation>
<xs:documentation>
Configuration of a syslog file appender for the audit log. This writes to a local file without any encryption or tamper detection applied to the file.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="truststore" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - can we define more than one truststore in java? The normal way seems to be to set -Djavax.net.ssl.trustStore, and there is
already one in authenticationType. It looks like there might be a way, although we would need to extend syslog4j to be able to use SSLContext.
Configuration of a keystore to use to create a trust manager to verify clients.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-certificate-authentication" type="keyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
TODO - Look into if it is possible to extend syslog4j to use SSLContext.
Configuration of a keystore containing a client certificate and private key, e.g. in PKCS12 format.
</xs:documentation>
</xs:element>
<!-- TODO other configuration, such as retries etc. -->
</xs:sequence>
<xs:attribute name="protocol" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="udp"/>
<xs:enumeration value="tcp"/>
<xs:enumeration value="tls"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="host" default="localhost"/>
<xs:attribute name="port" default="514"/>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
+*jboss-as-jmx (jmx subsystem)*+
References the appenders set up in the audit-log-appenders section. This allows for both shared and separate audit logs for core management operations and jmx operations.
<xs:complexType name="subsystem">
<xs:sequence>
<xs:element name="expose-resolved-model" type="resolvedModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="expose-expression-model" type="expressionModelType" minOccurs="0" maxOccurs="1"/>
<xs:element name="remoting-connector" type="remotingConnectorRefType" minOccurs="0"/>
<xs:element name="audit-log" type="audit-logType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="audit-logType">
<xs:annotation>
<xs:documentation>
Declaration of management operation audit logging configuration.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="simple-appender" type="audit-log-appender-refType" minOccurs="0">
<xs:annotation>
<xs:documentation>
A reference to an appender defined in the audit-log-appenders section of standalone.xml or host.xml
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="syslog-appender" type="audit-log-appender-refType" minOccurs="0">
<xs:annotation>
<xs:documentation>
A reference to an appender defined in the audit-log-appenders section of standalone.xml or host.xml
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
<xs:attribute name="log-read-only" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
Whether operations that do not modify the configuration or any runtime services should be logged.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="enabled" type="xs:boolean" default="true">
<xs:annotation>
<xs:documentation>
Whether audit logging is enabled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="audit-log-appender-refType">
<xs:annotation>
<xs:documentation>
A reference to an audit-log-appender
</xs:documentation>
</xs:annotation>
<xs:attribute name="appender" type="xs:string" use="required"/>
</xs:complexType>
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18812]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 7 months
[JBoss Transactions Development] - Re: JTA 1.2 Implementation Work
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] created the discussion
"Re: JTA 1.2 Implementation Work"
To view the discussion, visit: https://community.jboss.org/message/816816#816816
--------------------------------------------------------------
Tom,
> Re: When something goes wrong internally to the implementation of the TransactionInterceptor or TransactionalContext, what RuntimeException should I throw?
> It doesn't seem to be specified, so I'm thinking I can just throw some Narayana specific RuntimeException.
>
> Can you provide an example, at the moment I am thinking javax.transaction.TransactionalException (from 3.7: Transactional Annotation)
Yes, I think I can use TransactionalException in the transaction interceptors. However, I was more thinking about what to do in the TransactionalContext. Here's an example:
The TransactionalContext needs to lookup the transaction manager. If this fails, a javax.transaction.SystemException is thrown. This has to be handled (it extends Exception) and the Context interface does not declare that any checked exceptions can be thrown from its methods. Therefore I need to wrap the javax.transaction.SystemException in some unchecked transaction.
TransactionalException is the only RuntimeException in the JTA 1.2 spec, so I'll just use whatever general unchecked exception we use in the JTA 1.1 implementation.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/816816#816816]
Start a new discussion in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 months
[JBoss Transactions Development] - Re: JTA 1.2 Implementation Work
by Tom Jenkinson
Tom Jenkinson [https://community.jboss.org/people/tomjenkinson] created the discussion
"Re: JTA 1.2 Implementation Work"
To view the discussion, visit: https://community.jboss.org/message/816728#816728
--------------------------------------------------------------
h3. Re: What's the best way to enable this feature in WildFly?
The Context needs to be enabled via a CDI Extension. I'm currently enabling this via a configuration file (javax.enterprise.inject.spi.Extension) placed in the META-INF of the application. I think this is the way to do this for applications that run in a simple CDI container. However, we can remove this burden for applications deployed to WildFly. It's quite simple to enable this Extension in a DeploymentProcessor of the transactions SubSystem. However, we would need to either, enable it for all deployments, or just those that use @TransactionScoped (I don't yet know how to detect this).
Does enabling the extension when an application does not use it add overhead to the application? Maybe provide a way to disable it rather than enable it if so?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/816728#816728]
Start a new discussion in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 months