VM username should be the users username from access token, rather than a random one.

[marrobi]

No description provided.

[tamirkamara]

I might be mistaken but this isn't something easy to do -
Currently the API is the place where the user identity is known but we don't pass that along to porter. In order to do this we'll need to add the requestor identity as a property in all messages to the resource processor as we don't know which bundle will require it.
@marrobi Have I missed anything? Is this something we'd like to do?

[marrobi]

I think we need to pass the requester user object ID (not sure if we can deduce email or that would be needed too) through to porter. For some services, such as AML compute instances we also need to provide the AAD user object ID (manually at present).

[tamirkamara]

I think we need to pass the requester user object ID (not sure if we can deduce email or that would be needed too) through to porter. For some services, such as AML compute instances we also need to provide the AAD user object ID (manually at present).

I guess this is now a different requirement / usecase as the object id isn't much different than a random vm user name as for the person they both are meaningless.
Maybe a better way to phrase this would be: we want the API to extract details from the token and be able to inject them into the action request. username for create vm, aad id for aml compute...
wydt?

[marrobi]

The email is part of the User object once logged in. Where we call:

        user_resource, resource_template = user_resource_repo.create_user_resource_item(user_resource_create, workspace.id, workspace_service.id, workspace_service.templateName, user.id)

we could pass the complete user, and then include the email as part of the parameters.

[jlabhard-sg]

Bringing this old issue up as this would be something we need.

We would like for the user information to automatically be sent to porter instead of having to specify it manually. Our use case is enabling SSH access using Azure AD for VMs in an unrestricted workspace.

Is it something that is planned to be implemented, or is there a way to somehow pre-fill the template with this information? I have looked into it but couldn't find a working approach.

[marrobi]

Not planned, don't think it would be too hard.

The user id, and maybe username could be passed in the service bus message from the API to the resource processor, then it would be available in porter.

If passed the user into get_resource_request_message_payload here -

AzureTRE/api_app/service_bus/resource_request_sender.py

Line 57 in 6d589c4

content = json.dumps(resource_to_send.get_resource_request_message_payload(operation_id=operation.id, step_id=first_step.id, action=first_step.resourceAction))

So bits want will need adding as a property to the payload here -

AzureTRE/api_app/models/domain/resource.py

Line 56 in 6d589c4

def get_resource_request_message_payload(self, operation_id: str, step_id: str, action: RequestAction) -> dict:

"user" : {
"id": user.id
"name": user.name
"email": user.email
}

Or similar - probably want username... which isn't any of these.

The resource processor should then pick it up here -

AzureTRE/resource_processor/resources/commands.py

Line 49 in 6d589c4

# 3. msg body root (e.g. id of the resource)

- so no change needed, just use the new property name, say user in the bundle, and then access the properties in terraform.

Think you could do a PR? Happy to help iterate with you.

[jlabhard-sg]

I will unfortunately not have time to work on a PR for the next two weeks. It is not an urgency on our side however, so I can have a look after that.

[marrobi]

@jlabhard-sg I had 30 mins or so free at the end of the day:

Created a draft PR - #3770 Welcome your input - is this what you need?

[jlabhard-sg]

Hi @marrobi,
This seems perfect. The username doesn't necessarily need to be set to the base VM user, as long as they can be added in a custom template, which seems to be the case here.