VMware Cloud Community
ggiani
Contributor
Contributor

How to get current logged in user in a Composite Blueprint, using a VRO Script Action?

My code is as follows:

var username = Server.getCurrentLdapUser().userPrincipalName;

var username = username.substring(0, username.indexOf("@"));

System.log("username is: " + username);

If I put this in a VRO workflow it works.

If I put this into a XaaS form it works.

If I put this into a Composite Blueprint (Property Def - drop down list is my only choice), I get the following result:

cafe-wOLc5bZsJw

I need the username to be returned in both a XaaS form and a Composite Blueprint. Why does this not work when applied to a Property Definition in a Composite Blueprint? How can I get this to work in a Composite Blueprint?

I need a String value username to be returned (like in a workflow or XaaS form) but get the strange value above in a Composite Blueprint. I tried converting it to String which did not help. Any ideas?

Reply
0 Kudos
8 Replies
eoinbyrne
Expert
Expert

Any internal portal requests (for widget content, etc) are made by the cafe user. In an XaaS context, in the form builder you can access the ID of the requesting user by drilling into the schema when setting the value for a field (assuming you want to set the ID into the form - btw IMO, this is not neccessary as XaaS requests always include the "__asd_*" fields such as

"requested_by"

"requested_for"

and such like. You sort of get them for free after submission if you will)

Reply
0 Kudos
ggiani
Contributor
Contributor

Thanks for the reply. So are you saying this can NOT be done in a composite blueprint because the "cafe" user handles requests?

Reply
0 Kudos
eoinbyrne
Expert
Expert

When you say Composite Blueprint, what do you mean?

Generally (for me at least) there are two ways to think of data values in a Blueprint

1. In the Design view (Design panel), values are defined either as standard blueprint attributes (Memory, CPU, etc) or as custom properties attached directly or from PropertyGroups

2. After the blueprint is published, when you open the request form in the Catalog the request form is displayed - this is the request presentation

So, do you mean in Design or in presentation? I'm assuming presentation because the "cafe" user manages all internal requests to do thing like

- look up blueprint definition

- retrieve custom properties

- generate the request form to be displayed to you

- execute any custom actions in vRO which are tied to controls in the form (values, constraints, etc)

However, when you access the portal, your LDAP principal is available (since you had to log in to get there). If you submit any request it is made using your ID - cafe user only handles generation and display of the form.

I supposed I'm still not 100% clear what you want to do? Do you need to display the ID of the requesting user in the form? Or something else..?

--EDIT --

Also, are you trying to do this in a Custom Form on the Composite Blueprint?

-- EDIT 2 --

Did a quick check here and have wrapped my head around what you have tried - you're using a vRO action as an external field value in the form? And using Server.getCurrentUser() gives the ID of the user running the action which as I've stated will be the cafe user while the form is being built for presentation...

If you're using XaaS you can access the logged in user ID (& a whole lot more besides) by choosing to bind a "Field" and then drill down through the content of the Request Info object to get the value you need.

In the Custom Form you have to choose edit the field and set the "Value source" to "Bind field" - this will give a (much smaller) list of fields but "Requested for" is present which should suit your needs?

Reply
0 Kudos
ggiani
Contributor
Contributor

To clarify, I am trying to get a Script Action to return the logged on user on the Composite Form itself. We do not use custom forms.

Specifically: in the VRA 7.5 GUI

Administration, Property Dictionary, Property Definitions:

Data Type: String

Display as: Dropdown

Values: external values

  -Script Action: points to my script (which uses the code mentioned in the thread to return the logged on user)

This Property Def is then applied to my Composite Blueprint (no custom form used) in the Properties, custom properties tab.

...Go to "Catalog" and click on the blueprint. If I click the dropdown it returns the "cafe" user and not me.

If I do all this in a XaaS form using the same script it works as desired: returns the logged in user (me).

Clear now?

Reply
0 Kudos
eoinbyrne
Expert
Expert

Yep, now I understand and I think what you want cannot be done unless you compromise a little.

OK, so as I said the action supporting the PropertyGroup integration will be executed in vRO as the cafe user and so Server.getCurrentLdapUser or Server.getRunningUser will only ever return that name as this will be only name vRO has in that context - it cannot 'see' the portal page you have open and has no reference to it.

For XaaS (in presentation only or after submission?) the actions must be run as the logged in user which you have proved so far.

Can I ask what the aim is if you get this working? As in, what do you plan to do with the value? If you get it working the way you want it can only ever have 1 value. If it's ownership or ACL related then should that value not come from a static list anyway? In which case the compromise might for your action to do something one of the following

-- load the list of usernames from AD base on a group filter

-- load the list of usernames from a ConfigurationElement

-- load the list from a static array defined in the action code

Reply
0 Kudos
ggiani
Contributor
Contributor

I am attempting to restrict who can request certain products (for instance older O/S's like Windows 2012 R2). Users need to be members of a certain AD group to be able to submit such requests.

I realize, of course, this can be done with an entitlement but the issue is that users cannot perform Day 2 actions on existing deployments (and we have MANY - thousands) if they are not entitled to the blueprint. Changing the entitlement, therefore, would NOT go over well: MANY people would be extremely unhappy.

So my clever solution was to add a property. I got it to work by using the Username of an existing input, since we're already asking for a user ID (and that user would be given local Admin rights to the server). This new property queries the user to see if they are in a particular "Authorized" group and returns ONLY that group (if they are a member). The property is required so, only if they are a member can they satisfy the required input (by selecting the returned group in the dropdown). If they are not in the group, the required input can only be blank and they cannot submit.

I originally wanted to simply add a new required property that cannot be satisfied and everything would work: Day 2 actions would still work, but NO new provision requests would be allowed. The issue is it's NEVER that simple and management wants "exceptions" to be allowed.

So...back to my current solution, it has a big loophole: All the user has to do is get a username that is already a member of the "Authorized" group (and that is very easy for them to do). They can use THAT username and submit the request.

My new solution would rely on the currently logged on user to query for membership in the "Authorized" group so there's no "cheating".

Reply
0 Kudos
eoinbyrne
Expert
Expert

Sounds like heaps of fun Smiley Happy It's always nice when you have side-step / re-implement product features to make users happy Smiley Happy I have done some stuff with entitlements before to get to places sort of like where you want to be but nothing that complicated.

Perhaps another approach might work- (depending on the day-2 actions you need here, but anyway, a though experiment if you'll permit me?

What if you provided access to those day-2 actions via an XaaS - e.g., multi-step form where user is asked for

- Deployment to modify (from list of available / entitled to see)

- Action to perform (from list of available / entitled to see)

- any parameters for the action

Since as you say, the XaaS can detect the logged in user and compare their AD memberships with the allowed ones. it would then be easy to prevent them submitting (by disabling mandatory fields or) or else just let them submit and fail the request with appropriate error messages.

Assuming the user is valid and the workflow can start then it's easy enough to have vRO

- locate the action on the resource

- request the action form and then complete and submit it

I'll be the first to admit it's a clunky way to get what you want, but as stated at the beginning you're already in weird territory anyway.

If you have a look here - Executing Day 2 Actions with the vRA 7 REST API | | VMtoCloud.com you'll find a worked example (using curl and python but the APIs are the same)

I have used this approach as part of an XaaS before like this

-- XaaS provides simplified form to request server

-- User submits XaaS which confgures and submits a new Deployment request from a Blueprint CatalogItem as the service user (only user entitled to request blueprints)

-- XaaS waits for Deployment to complete, then locates 'Change Owner' action on the Deployment resource

-- XaaS retrieves form for 'Change Owner', configures it with the principal of the XaaS requestor and submits

-- XaaS waits for ownership change to complete

-- XaaS completed and server belongs to original requestor

It works quite well and the action code is not that scary from a vRO perspective.

Reply
0 Kudos
ggiani
Contributor
Contributor

I thought about the XaaS route but that's "too big of a change". Users are used to using the composite, now they'd have to use the XaaS form and NOT use the Composite (which we cannot hide in any way). We have this very issue with clusters: We present a XaaS form to collect all the inputs and it provisions the nodes using the composite behind the scenes. We tell users to NOT use the composite for those. Introducing a new XaaS would open a whole can of worms.

...and yes the way we do it is probably a little convoluted. I did not set it up this way but am stuck with what we have of course. PLUS we are moving to VRA8 (that's gonna be real "fun") very soon and don't want to spend a tremendous amount of time in our current 7.5 environment. Just keep it running, fix small stuff kind of thing... as we shift our products over to the new version.

I am experimenting with a custom form as that could be a good compromise. It kind of blends Composite and XaaS into one so there'd be no new form for the user to be aware of. I suspect this may work in a custom form (but I need to try it and find out).

If all else fails, I'll have to present the options to my team and the boss and see what everyone thinks.

It's never easy! I appreciate all your help and suggestions!

Reply
0 Kudos