Build User API

[jbonnet]

@dang03, @srodriguezOPT, @trakadasp We need to progress on this front (as well)... There's a draft of the BSS<->GKAPI, where the user is always Unknown and the password None, but we need the rest... Can we start thinking of registering a user? Managing (i.e., updated it, delete, ...)?

[santiagordguez]

There is a "work in progress" version of BSS that registers the user with the command $http.post(ENV.gatekeeperApiEndpoint+'/users', data) where data is var data = { "username": username , "secret": secret };

But the BSS registration as microservice is still pending. @dang03 , do we have any update on this?

[santiagordguez]

Hi @jbonnet ,

I'm testing the login with the "Unknown" user:

POST http://sp.int3.sonata-nfv.eu:32001/api/v2/sessions with json body = { "username": "Unknown" , "secret": "VW5rbm93bjpOb25l" } returns a 400 error code: "Unprocessable entity: missing user name"

trying with { "name": "Unknown" , "password": "VW5rbm93bjpOb25l" } returns a 500 error code: "#<NoMethodError: undefined method `authenticate!' for #>"

[dang03]

@srodriguezOPT I sent you an email with about the BSS registration as a microservice. I'm going to upload the User Management code presented in the F2F to the GK repo. Then, in order to manage users (update info, roles, delete...) implementation is required.

[jbonnet]

hi, Santi, Today I’m in a meeting in Aveiro, but I’ll try to look into this: 500 error should never reach the BSS. Have you tried with password ‘None’?

Best

On 22 Mar 2017, at 08:17, Santiago Rodríguez notifications@github.com wrote:

Hi @jbonnet https://github.com/jbonnet ,

I'm testing the login with the "Unknown" user:

POST http://sp.int3.sonata-nfv.eu:32001/api/v2/sessions http://sp.int3.sonata-nfv.eu:32001/api/v2/sessions with json body = { "username": "Unknown" , "secret": "VW5rbm93bjpOb25l" } returns a 400 error code: "Unprocessable entity: missing user name"

trying with { "name": "Unknown" , "password": "VW5rbm93bjpOb25l" } returns a 500 error code: "#<NoMethodError: undefined method `authenticate!' for #User:0x00556f5415c160>"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sonata-nfv/son-gkeeper/issues/450#issuecomment-288327597, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAuQ4RjaLN0xXElePRg4dpW7s5t3FJxks5roNkmgaJpZM4MRAUZ.

[santiagordguez]

Hi,

yes, { "name": "Unknown" , "password": "None" } produces the same result.

Anyway, the data should be { "username": user_name, "secret": our_base_64_secret }, doesn't it?

[dang03]

Hello, the User Management, in api/v1/login/user API, expects the next HTTP request in order to login a user:

"HTTP_AUTHORIZATION" header set to basic plus the username and password encoded in base64. The request body is empty.

An example is: url = "http://127.0.0.1:9292/api/v1/login/user" headers = {'authorization': "Basic YWRtaW46YWRtaW4="}

where YWRtaW46YWRtaW4= is: Base64.encode64("developer123"+":"+"1234")

Then, in the workflow between BSS -> GK -> UM: If BSS sends the login message as next format { "name": "Unknown" , "password": "None" } to /api/v2/sessions, GK must translate the request to the expected format and forward it to /api/v1/login/user. The alternative is the BSS to send the login message in UM expected format.

[santiagordguez]

Hi,

yes, BSS sends the login message as json data: { "username": user_name, "secret": our_base_64_secret } where our_base_64_secret = Base64.encode64(username+":"+password)

On the other hand, we will need the UM's user_uuid to later retrieve the list of licences of that user, right? (GET .../licences/:user_uuid) Maybe BSS can get it in the response of the login request.

¿what do you think?

[dang03]

Hi, It makes sense. It should be easy to return the generated ID for the user within the response. I'm not sure if the access_token also includes this ID, I'm going to check it.

About the login json data, the GK API will have to forward then the login request with the header Auth. including the content of your "secret" json field.

[dang03]

Hi @jbonnet The User management code is up, now to make it work in the integration environment, we need to set the correct address and port in its settings. I have done a bit of research in other GK modules and I see this:

• in son-gtkapi config: users:

  url: http://localhost:5800 model: User environment: USER_MANAGEMENT_URL

but port 5800 is assigned to Record Management in the Dockerfile: ENV RECORD_MANAGEMENT_URL http://son-gtkrec:5800

What do you suggest?

[jbonnet]

For sure was a copy&paste error… can you fix it? Give it an unused one. Also, you need to add the Usr. Mgmt. container to Jenkins configuration… just let me know if you need help

On 23 Mar 2017, at 15:29, Daniel notifications@github.com wrote:

Hi @jbonnet https://github.com/jbonnet The User management code is up, now to make it work in the integration environment, we need to set the correct address and port in its settings. I have done a bit of research in other GK modules and I see this:

in son-gtkapi config: users:

url: http://localhost:5800 model: User environment: USER_MANAGEMENT_URL but port 5800 is assigned to Record Management in the Dockerfile: ENV RECORD_MANAGEMENT_URL http://son-gtkrec:5800

What do you suggest?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sonata-nfv/son-gkeeper/issues/450#issuecomment-288756692, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAuQ_MEMbBJqe9F_RqADUYomEUdmZhFks5roo_TgaJpZM4MRAUZ.

[jbonnet]

@srodriguezOPT Now, yes, logging user Unknown with password None is ready to be tested by the BSS.

Registering new users is still on hold (@dang03?)

[dang03]

@jbonnet I edited Jenkins the configuration for DEVELOPMENT env. in Jenkins for son-gtkusr (Keycloak is missing here). What is pending is the jenkins configuration for the INTEGRATION env. I need to configure son-gtkusr and Keycloak dockers there to deploy them. Then User Management will be available to register users.

[jbonnet]

Great, @dang03, thanks!

[jbonnet]

Hey @dang03 Are the son-gtkusr logs available? I'm getting <h1>Internal Server Error</h1> with

$ curl -d '{"username":"test", "email":"a@example.com", "credentials":[{"type":"password", "value":"123"}], "attributes":{"developer":["true"]}}' sp.int3.sonata-nfv.eu:5600/api/v1/register/user

[jbonnet]

Three other things, @dang03:

1. Shouldn't attributes be an Array of key:values?
2. Shouldn't "developer":["true"] be "developer":"true" (a single value, instead of an array)?
3. Are you expecting a developer to also be (e.g.) an admin?

Thanks,

[dang03]

Hi @jbonnet, The integration between son-gtkusr and keycloak in sp.int3.sonata-nfv.eu is not ready yet, so it is probably to get 500 errors. I suggest to wait until we fix it to test its features. Anyway, the logs URL is: http://sp.int3.sonata-nfv.eu:5600/admin/log

To your other points:

1. and 2. This is a Keycloak restriction, as it is implemented in that way. Even if you have a single value, Keycloak expects an array :(
2. In the examples I wrote in the wiki I added 'developer':[true], 'admin': [false] just to state that we could mix several roles, however it was just an example. I don't expect a developer to be admin too, but it could be a possibility?

[jbonnet]

@dang03 No problem, we can leave with that. No, I don't see a developer do be also an platform admin. But how does this play with the groups?

[jbonnet]

Closed by #533