HP Cloud Service Automation - Part 6

HP Cloud Service Automation - Part 6

LDAP is a means to integrating a customers directory service with HP CloudSystem so that we can specify which groups of users are allowed to logon to CSA and the Marketplace Portal and do/see exactly what.

Edit the Organization as follows:

LDAP Server Information:
Hostname: FQDN of your Domain Controller / Directory Server
Port: 389 (I'm not using security but in Production you should. You will need however to address importing the customer's root SSL certificate into CSA to ensure it is trusted)
Base DN: DC=lab,DC=local (change to what is appropriate for your environment)
User ID: CN=cloudsystem_service,OU=Service Accounts,OU=Lab,DC=lab,DC=local (This is a service account with a long, non-expiring password to allow CSA to query the Directory Service)

 



LDAP Attributes:
User Email: mail
Group Membership: member
Manager Identifier: manager
Manager Identifier Value:dn
User Avatar: avatar

User Login Information:
User Name Attribute: sAMAccountName
User Search Base: OU=Users,OU=Lab
User Search Filter: sAMAccountName={0}
Search Option: Search Subtree - selected

Now, this is for Microsoft Active Directory, you may need to edit some values if using something else. When you are finished validate the settings via the Look Up User button in green shown above. Here is one with a search for a user jsoap2 and the successful result:

Now you can go to the Organization Access Control section and add in the groups to assign permissions as follows:

We can use these permissions in Catalog, Offerings and Approval flows. We'll look at Catalogs next:

Catalogs are one way to organise the offerings you are publishing. You can publish everything to the Global Shared Catalog but you may have times when you want more control. You may have a set of Developers or people who only need to see one particular Offering and no others. You ensure that the group is listed as a Service Consumer in the Organizational screen above and then add that group to the access control tab of the Offering and publish it. Only that group can then se it in Marketplace.

Now, Catalogs contain Categories. These are just for grouping similar designs. You get 14 default ones when you create a new Organization but these can be trimmed down / replaced with more appropriate ones if you wish.

Click Add Category to create a new one

 

You can Delete any other ones you don't need here. If an offering has already been published to a Category the Delete option will be unavailable. Again, best do thinking up front and Organize things in advance as much as possible.

Approval workflows require LDAP integration. There are four types:

• Delegated Template - provides access to custom OO workflow for more advanced scenarios
• Named Approver Template - can point to list of specified users in LDAP
• Named Group Template - can point to a single LDAP Group that has up to 10 users in it
• User Context Template - can use the LDAP manager's field to determine who has approval rights

You usually select a list of users or a group and choose how many people much approve the request before it is passed (any 2 or 3 for example). You also specify what happens if no one is around to approve it, does it get automatically approved or not and what is the defined waiting period.

Here is a Named Approver example. You type in the username and click Add Approver and it should resolve and add the user in.

Here is an example of a Named Group Template. You have to enter in the DN of the group (you can specify an OU and it shows all the group DNs in that part of the LDAP structure).

Now we set the number of approvers slightly higher.

When a new subscription request is made for this offering, the named approvers are emailed to say they have pending approvals waiting. They log into CSA (not the marketplace) and approve the pending request. The Requestor gets an email to say their request has been approved and another when the VM/instance is build and ready.

Now, when you publish an Offering to the Test Catalog you can change the Approval Policy and what actions it is used under.

You can also get more granular so approval to reboot etc has to be approved!

That is about enough to fill anyone's head so I'll leave it there! You will need an email server and SMTP integration in the Organization to see the notifications around approvals. There isn't a hyperlink to my knowledge to enable easier approvals but the custom OO flows could be used to generate one in the email at a guess.