FreeIPA admin roles

[jacobblock]

Hi folks,

I've been poking at bit at VersityGW (awesome project!) and have FreeIPA IAM working. I noticed all accounts get assigned RoleUser at iam_ipa.go#L158. Curious what it could look like to get some accounts RoleAdmin. Potentially:

1. Introduce a flag like --ipa-admin-group-cn (cn=common name).
2. Check for cn presence in GetUserAccount?
3. Profit?

Thanks!

[benmcclelland]

I think we can store the role alongside the secret since we are serializing this to json here. Here is a proposal #2128 along with the create/update user that was missing before for easier setting of the account info. This can still be managed server side only if needed as well.

[jacobblock]

Appreciate the quick reply and code! I might have had the wrong initial impression of FreeIPA integration. Here's what I had understood:

1. CreateAccount API is basically IdP management, and IAM IPA not implementing it was intentional because otherwise you're looking at ipa user-add type of RPCs and it gets messy. This was done for LDAP in a pretty standard kind of way with a lot of flexibility through flags.

2. Every IPA user has it's own IPA vault storing s3 credentials. The IPA vault is already performing sufficient encryption itself, and Versity just needs to authenticate bucket access with the stored secret.

A few questions (with my limited understanding of Versity) about your CL:

1. It looks like you're embedding multiple accounts into a single vault now that CreateAccount is implemented. So now you'd have buttons for creating users, but it would be tied to the particular IPA user you've provided credentials for because it's stored in that user's vault. Is that accurate? That seems like it might get confusing with two dimensions to account handling.

2. Personally, I like FreeIPA's group management and the gap for Versity was just needing a group --> role mapping. With the proposal, I don't think we'd have that yet since we'd be creating users+groups local to Versity, instead of being managed externally in FreeIPA.

Am I off basis with the above?

Cheers
Jacob

[benmcclelland]

Appreciate the quick reply and code! I might have had the wrong initial impression of FreeIPA integration. Here's what I had understood:

1. CreateAccount API is basically IdP management, and IAM IPA not implementing it was intentional because otherwise you're looking at ipa user-add type of RPCs and it gets messy. This was done for LDAP in a pretty standard kind of way with a lot of flexibility through flags.

That's correct and CreateAccount here still doesn't create the IPA user — it only creates an IPA vault for an already-existing IPA user and stores the S3 access/secret pair. If the IPA user doesn't already exist, vault_add will fail with a not-found error. Maybe this is a good argument for leaving this unimplemented though. I was just thinking it might make the gateway user management slightly easier.

2. Every IPA user has it's own IPA vault storing s3 credentials. The IPA vault is already performing sufficient encryption itself, and Versity just needs to authenticate bucket access with the stored secret.

Correct

A few questions (with my limited understanding of Versity) about your CL:

1. It looks like you're embedding multiple accounts into a single vault now that CreateAccount is implemented. So now you'd have buttons for creating users, but it would be tied to the particular IPA user you've provided credentials for because it's stored in that user's vault. Is that accurate? That seems like it might get confusing with two dimensions to account handling.

No, but the naming is confusing. vaultName field in IpaIAMService is used as the vault name template, not a single shared vault.
The username parameter scopes the vault to the IPA user identified by account.Access. So each IPA user gets their own vault named vaultName, under their own user container. It's not one vault holding multiple accounts. However, the first point still stands: CreateAccount calls vault_add with account.Access as the IPA username, meaning that IPA user must already exist in FreeIPA — this does not call user_add. It just creates the vault for an existing user and stores their S3 credentials in it.

2. Personally, I like FreeIPA's group management and the gap for Versity was just needing a group --> role mapping. With the proposal, I don't think we'd have that yet since we'd be creating users+groups local to Versity, instead of being managed externally in FreeIPA.

The current PR code stores the Versity Role inside the user's own vault alongside their S3 secret — meaning role assignment is managed by whoever has write access to the vault, not via FreeIPA group membership. We could change this to get group-to-role mapping the way you're describing, this seems like a reasonable way to do it as long as there is a group that could describe the versitygw role correctly. I'll update the PR with the proposed changes when I get a chance.