Hide Forgot
Domain management requests are handled using a stateless protocol. For HTTP, authentication occurs with each request. For Native authentication, it happens on the establishment of the connection. Other than this, there is no 'authenticated session'. Because there is no 'authenticated session', 'login' and 'logout' events can not be audited. Instead. audit messages are logged when an operation is received from the user.
The fundamental problem we have is multiple components are involved in negotiation the authentication for the connection, we have Remoting, SASL and the security realms but it is a collaborative effort for them to agree - as we were talking today we are also missing a concept of management for currently connected / established connections which also fits quite tightly in this area. Need to look properly into which options we can follow for both long and short term.
I am ACKing this one on the basis that I will increase the level of audit logging we have around authentication for management. However we do not have a concept of an authenticated session so we do not have a login / logout around a session to audit.
To clarify once and for all - there is no such thing as a login and logout in EAP 6 for domain managament - there is no authenticated session to wrap with such audit events, what we have is for the Native interface authentication on the establishment of a connection and for the HTTP interface authentication we have authentication on the receipt of a request. So for this task I can add audit entries for successful and failed authentication attempts - the successful ones may be a little redundant as the users operation request might also log an audit event but the failure ones will be the most useful.
I'm adding a NACK to this, and it's definitely not a blocker. Authentication for management operations is per-request, and there are audit logs for every change, and it can be enabled for reads as well. We shouldn't log anything about transport activity as it is not useful information. A client might reuse a connection, and it might not, the fact that it reuses a connection isn't of security interest. It would be volatile and lead to confusion.
Just to be clear though I think its fine to add a feature for rejected requests due to lack of authentication, but thats an RFE not a blocker, and we are out of time for the 6.4 feature schedule.
Changed issue type to RFE, cleared the blocker?
Closing out old BZs, this is an RFE not a bug, and there are no more feature releases for EAP 6.x. An RFE exists for this request for a future EAP feature release.