Ceph » rgw

(It would be nice to ensure that identity is logged appropriately for other auth strategies, too--we already have info specific to STS)

I agree, Matt. I'll take a closer look at the other auth strategies and try to determine what makes sense to log for each.

matt: I've taken a close look at each of the existing auth engines and here is my summary of what each does and what additional info we should include in the ops logs for each. Let me know if this sounds right to you?

keystone::EC2Engine             Delegates S3 key pair check to Keystone. TODO: log the access key ID.
LDAPEngine                      Uses specially formatted, b64 encoded JSON access key. Should NOT log access key because it contains b64 encoded clear text user password. TODO: nothing
LocalEngine                     S3 key pairs are stored locally in RADOS for each user. TODO: log the access key ID and, if applicable, subuser
STSEngine                       Already logging the claims (including role name and role session name). TODO: log the access key ID.
S3AnonymousEngine               No access key to log. TODO: nothing 
SwiftAnonymousEngine            No access key to log. TODO: nothing 
swift::ExternalTokenEngine      Just checks the swift token via a configurable external URL. TODO: Log subuser.
swift::SignedTokenEngine        Rados implementation of Swift tokens. TODO: Log subuser.
swift::TempURLEngine            TODO: Log which temp URL key was used? (1 or 2)
keystone::TokenEngine           Keystone doesn't support RGW's subuser concept. TODO: nothing.

looks sane, Cory