Description:
Upon logging into Morpheus platform, if you click on right side top and goto user settings. We have a flexibility to use create Windows/Linux secrets which can help logging into the virtual desktops.
Now the real ask here is on the same user settings, we may need common user inputs like Cost center code, Application type, Application Env which are tied to an end user to auto load during a catalog submission.
As we get matured, end users are looking on some intelligence in the system to tackle repeated user inputs to tie up to his profile and auto load. Windows Operating system input is different from RHEL Operating system inputs, but there are common attributes to both the catalog which can be loaded directly from user settings. If, needed user must have a flexibility to modify during the submission of a catalog.
It should be useful to be able to tag users. For example I would like to be able to select users that belonging to the same role but are from specific companies or departments or something else. This could be useful for reporting aspects
Normally this is represented by ‘Groups’ in Morpheus. You can clone a role, and alter the Group access. Groups in most situations represent an Org/Business unit accessing Morpheus, not Cloud infrastructure.
Tags should be useful for reporting scopes. For examples in the same role/group I could have people from different sources (company, internal areas, …) and in reporting I would like to aggregate on custom tags to obtain differnt grouping
With how Morpheus currently functions, this would ideally be the Labels functionality. That said, you do lose the key:value pairs with labels so you’d probably need another identifier.
Also, @Venkat from your ask, could the group labels control some of this? Do they all have to be applied to the users? If it would have to be applied to the users, I’d imagine the Role would dictate what get’s assigned.
Lastly, I did want to note that if you are using SAML based authentication to Morpheus, the SAML provider can be configured to pass additional values via the assertion. These are then available via the <%=user%> variable.