👍 but you can please update RemoteApplier too?

sure, I find user_info is missing,
should I load user_info to check user type?
or without loading user_info can i proceed as I get userid

  const AuthInfo info;

  string key = "aws:userid";
  string value = info.acct_user.id;
  s->env.emplace(key, value);

your use of AuthInfo info looks correct to me 👍

thank you 👍🏻 pushed new update.

👍 but you can please update RemoteApplier too?

@cbodley does this really apply to RemoteApplier?

doesn't RemoteApplier support all the other interactions with iam policy? RemoteApplier::is_identity() matches policy Principals based on info.acct_user.id, and RemoteApplier::load_acct_info() produces a s->user whose uid comes from info.acct_user

yes, but RemoteApplier is meant for Keystone/LDAP users, whereas GetCallerIdentity is mostly for IAM user/root user or roles.

We can add functionality for aws:userid to RemoteApplier, and then we will need to add implementation to its get_caller_indentity() method also? (right now it returns nullopt)

yes, but RemoteApplier is meant for Keystone/LDAP users, whereas GetCallerIdentity is mostly for IAM user/root user or roles.

this is probably analogous to 'federated users' in sts? but our existing code presents these as normal s3 users

so i think RemoteApplier::get_caller_indentity() would return the same kind of user arn that it matches through is_identity(): "arn:aws:iam::{account id or tentant}:user/{userid}"

ok, sounds fine to me. @ArbitCode : add implementation for get_caller_indentity() in RemoteApplier also

@pritha-srivastava I added imp for get_caller_identity() in RemoteApplier

driver->get_user() just allocates a handle, it doesn't load it from the backend - and we shouldn't try to load it here

RemoteApplier::load_acct_info() will have already loaded this 'shadow user' if it exists, or called RemoteApplier::create_account() to make a new one

if get_caller_identity() needs additional information from the RGWUserInfo, load_acct_info() should stash that in a member variable like we do with the account info:

  // account and policies are loaded by load_acct_info()              
  mutable std::optional<RGWAccountInfo> account;

but if we're just trying to be consistent with what we match in RemoteApplier::is_identity(), this alone should be sufficient:

return rgw::ARN(owner_acct_user.id, "user", owner_acct_user.tenant, true);

okay, but there was a example where driver->get_user() was used RemoteApplier::create_account().

Yes, Below is sufficient.

return rgw::ARN(owner_acct_user.id, "user", owner_acct_user.tenant, true);

shouldn't RemoteApplier::get_caller_identity be moved to previous commit?

@cbodley : are keystone/ldap users created under accounts? from the comments I see handling for global tenant/implicit tenants only.

are keystone/ldap users created under accounts?

no, RemoteApplier::create_account() only creates the 'shadow user' - no 'shadow accounts'

though once a shadow user exists, it is possible to migrate that into an account via https://docs.ceph.com/en/latest/radosgw/account/#migrate-an-existing-user-into-an-account