password for internal user not works with the header 'x-l7-passphrase'

[Sylvain RICHARD]

Hi

In the internalIdp I try to export a user/password, then import into a another API Gateway (the target gateway).

In the target Gateway, the user in created but the password cannot match. I cannot login.

{
  "name": "bob",
  "goid": "399027fda0393aacd3c5279babe2311c",
  "login": "bob",
  "enabled": true,
  "password": "$6$6qCwZjkoA7RB8vAA$GOgyd2iVYlQpQMlvL0fJMZGhf6mOAxMkgW4A0WZ47e1vygeHzCvqYyLRwggfKlEo6IvAoOJJPTlKo3OGinnW61",
  "sshPublicKey": "",
  "firstName": "",
  "lastName": "",
  "email": "",
  "replaceGroupMemberships": false,
  "memberOf": []
}

Note.

• export use internalUserByLogin(login)
• import use setInternalUsers
• I already tried the header 'x-l7-passphrase' for import export but that has no effect.

could you fix the usage of 'x-l7-passphrase' header for internalUserByLogin(login) and setInternalUsers ?

Thanks.

Sylvain

[Raju Gurram]

@Sylvain RICHARD

Let me see if I can reproduce it. Besides that, I assume, you must have encoded your custom passphrase and populated the x-l7-passphrase header with it while requesting the graphman.

[Raju Gurram]

@Sylvain RICHARD

Could you please try consuming a service defined with the below set of assertions to verify whether user's password is imported properly or not:

• Require HTTP Basic Credentials
• Authenticate User against Internal Identity Provider
• Return Template Response (Hello, ${request.authenticatedUser})

If you could consume the above service with the Bob user credentials, everything seemed alright. 

If you want to login to the gateway using policy manager using Bob's credentials, We should make sure him to be with one of the supporting Role.

[Sylvain RICHARD]

Hi Raju.

I create the user from my gateway A(source). (with the appropriate role)

I do the export from gateway A(source). And DROP the user.

If a do the import on gateway A(source) and B(target).

I can connect to A via the PolicyManager.
I cannot connect to B the PolicyManager. If I reset the password, it's ok.

I hope this clarifies that the password cannot be decode on gateway B.

Note. During the export the header 'x-l7-passphrase' has ne effect on the password encoding. Because actually, this header is not used to encode the password.

Regards
Sylvain

[Sylvain RICHARD]

The same password is available on the B gateway.

"password": "$6$6qCwZjkoA7RB8vAA$GOgyd2iVYlQpQMlvL0fJMZGhf6mOAxMkgW4A0WZ47e1vygeHzCvqYyLRwggfKlEo6IvAoOJJPTlKo3OGinnW61",

I imagine the decoding is specific for each gateway cluster.

could you fix the usage of 'x-l7-passphrase' header for internalUserByLogin(login) and setInternalUsers ?

[Raju Gurram]

@Sylvain RICHARD

Interesting. I agree that, x-l7-passphrase has no impact on transporting the internal user's password from one gateway to another. Neither the cluster passphrase has any impact on this. 

Fact is that user must be in some role for Policy Manager connectivity. 

For the same reason, we should consider exporting the user along with his roles information. Please do consider exporting his roles like below:

query roleByName($name: String!) {
  roleByName(name: $name) {
    goid
    name
    checksum
    roleType
    description
    tag
    replaceAssignees
    userAssignees {
      name
      login
      subjectDn
      providerName
      providerType
    }
    groupAssignees {
      name
      subjectDn
      providerName
      providerType
    }
  }
}

I'm sure, you would be able to login after getting his roles into the target.

NOTE: Dropping the user will not clear the user role assignments. Reintroducing the user with the same login will inherit the previous assignments automatically.

[Sylvain RICHARD]

Thank you Raju.

NOTE: Dropping the user will not clear the user role assignments. Reintroducing the user with the same login will inherit the previous assignments automatically.

This is a curious behavior.

You're right. It's the roles that were missing from the target.

So I see that this password is not encoded differently between the gateways.

The login error message "Invalid User Name / Password" instead of "User Not Authorized" put me on a password problem. And not the role.  

Sylvain

[Sylvain RICHARD]

Hi Raju, Hi all.

Raju, could you please confirm that the password is encrypted with the master passphrase?

This implies that the password cannot be read on the target gateway if the master passphrase is different. So exporting via the 'x-l7-passphrase' header would remain the best option, in the future.

I just looked at Role Management (RBAC).
In my opinion, Graphman is missing methods to export and then import user and group roles.

To export: getRolesForUser(user:)  and getRolesForGroup(group:)
Similarly, methods to import multiple roles are missing.
addRolesToUser(user) addRolesToUser(user) instead of looping through the addUserToRole(role, user) and addGroupToRole(role, group) methods.

Regards

Sylvain

[Raju Gurram]

@Sylvain RICHARD

Internal User's password is persisted in digest form. Hence, neither master passphrase not cluster passphrase influence them. Do you still see any problem moving them from one cluster to another?

Coming to roles, support is limited to user-role or group-role assignments only. In other words, you cannot create/update new or existing roles beyond this. But, we might be supporting deletion though. 

Roles (with minimal details) can be exported using below field methods

• roles
• rolesByName

Roles can be mutated w.r.t user/group assignments

• setRoles

[Sylvain RICHARD]

Hi Raju.

Thanks for the explanation about the encoding.

Everything is fine now.

I'm developing the functionality to export user or group roles using existing methods.(because setRoles can not import a role if a user is missing in the target API Gateway)

 

Thank you, have a nice day.

Sylvain