Using the Centrify Developer Platform

As my colleague Ben points out, the world of software has become one of interoperability and interaction through APIs.  Using libraries and APIs to construct a user experience is no longer the specialized domain of ISV’s building something specific and targeted at a distinct set of users.  Instead, everyone from application developers to IT and security professionals regularly look to integrate directly with the products they use at a programmatic level.

For IT and security professionals, the ability to tightly integrate and leverage a vendor’s product as a tool in their own workflow is paramount to their ability to service customers, whether it is end-users, management or a combination.  This, more often than not, means wearing that fancy hat with “Developer” stenciled across the front and using APIs to get work done. Centrify understands the importance of this need, and I am pleased to be able to highlight how we address this with our Developer Platform.

The Centrify Identity Platform

platform

At the core of everything we provide, is a very deliberate platform approach to building our products.  As you look to secure your enterprise, from adopting MFA everywhere, to ensuring that physical and virtual infrastructure credentials are secured and to managing the ever increasing demand that adoption of cloud services and mobile devices implies, our platform approach is the basis by which we provide you with:

  • ROI – One login for all your users, one security surface to manage for your IT and a single point of contact for management
  • Security – a single unified and consistent infrastructure which covers user access, privileged commands, mobile devices, web applications, and even local and cloud based infrastructure access and credentials.
  • Compliance management – a single pane of glass for reporting on access, usage and adoption

The Centrify Developer Platform

Okay, you get it, there is a platform behind the products – it has a lot of great functionality across a variety of use cases, a swish web based management and end-user interface… but, what does all this mean to a developer?

Enter the Developer Platform!

By building with a platform mindset on top of industry standards, we have built a product line that we think is very developer friendly. In fact, so friendly that we hold nothing back  This means that the entirety of our Centrify Identity Service, Centrify Privilege Service and Centrify Server Suite cloud service feature set is available to you as an API – today.  MFA, Application Access, Policy, Roles, Privileges, Resources, Accounts, Devices, Delegated RDP/SSH access, Events, Reports…. everything!  This is NOT a sand-boxed API for specific scenarios.  This is the very same API my colleagues and I in the engineering department use to build our products day in and day out.

We built our platform API using industry standard HTTP and RESTful concepts, utilizing JSON as a payload format for flexible, forward and backward compatible payloads.  This means you can interact with our API from any language (or just use curl!), from any operating system and from anywhere in the world.

restandjson

Combine that with first class documentation and scenarios available on our http://developer.centrify.com site, and the availability of sample libraries on GitHub (http://github.com/centrify), and there is a lot of power there!  Let’s look at some examples.

A Concrete Example #1 — Protecting Privileged Credentials from Outset

Whether the machines you manage are physical end-user laptops, hardware in your datacenter or VM’s in someone else’s, long gone are the days of inserting installation media and answering questions to provision a new resource. Instead, you likely use some disk imaging technology, or unattended installation process, or other automated means by which these resources can be initially created and provisioned. In doing so though, a classic problem arises – what do you set as the root (or local Administrator) password?  An unattended/automated system often leaves these images with a stock root password, which is either available by inspecting the automated scripts, or is simply “well known” to the IT organization.

We could simply change the IT playbook and include an instruction that after “Run automated install” the IT admin should “change password and add to Centrify Privilege Service.”  That means increased overhead, time and the potential for missing a step. A fact that, if true, even once could mean catastrophic exposition of data through compromised credentials. Instead, let us change the automated install itself so that the password starts out as a random value, unknown to anyone – and is there after managed automatically – ensuring that no machine image leaves IT without the root credentials being appropriately protected.

We could use curl commands to integrate into shell scripts, C# if we’ve built a .NET app which drives our automation, or Python… but let us use PowerShell for this example.

We grab the open source and free sample from here and begin typing.

Import-Module .\module\Centrify.Samples.Powershell.psm1

Straight-forward – include the sample module in our script so that we can interact with the Centrify API.  Note that the module itself is included in the sample, and is also open source.

First, we need to make sure that the IT admin provisioning the image is who they claim to be – allowing us to gate image creation with MFA:

$token = Centrify-InteractiveLogin-GetToken -Username “your@username” -Endpoint “https://corp.my.centrify.com”

Single line of code and full MFA experience = powerful.  We then kickoff our image installation, which I’ll leave as an exercise to the reader.  When it finishes though, we want to add this machine and its root account to the Privilege Service for management, so we describe it with a simple dictionary object:

$restArg = @{}

$restArg.Name = $machineName

$restArg.FQDN = $machineFqdn

$restArg.ComputerClass = “Unix”

$restArg.SessionType = “Ssh”

$restArg.Description = $machineDescriptionFromTicket

Then use the /servermanage/addresource API to add it:

$addResourceResultId = Centrify-InvokeREST -Method “/servermanage/addresource” -Endpoint $token.Endpoint -Token $token.BearerToken -ObjectContent $restArg

With the machine now accounted for, we pair the root account we just auto-created during imaging, with a random password, and add that with the /servermanage/addaccount API:

$restArg = @{}

$restArg.User = “root”

$restArg.Password = $password

$restArg.IsManaged = $true

$restArg.UseWheel = “false”

$restArg.Description = “Root account for ” + $machineDescriptionFromTicket

$restArg.Host = $addResourceResultId

$addAccountResult = Centrify-InvokeREST -Method “/servermanage/addaccount” -Endpoint $token.Endpoint -Token $token.BearerToken -ObjectContent $restArg

That’s it!  Barely 15 lines of code around our already automated machine imaging process and we have ensured that all machines get a unique root account password which is managed and available in break-glass scenarios, and adheres to best practices for protecting administrative credentials. For that matter, we can ensure that password is almost never needed, by also allowing delegated remote access via SSH. This type of tight integration with automation brings down the time necessary to correctly and securely manage resources, while also ensuring that the human factor is removed – made possible by open, accessible, easy to use and documented APIs.

Concrete Example #2 — Business Intelligence

One of the staples of our platform is a flexible and rich source of data, including a SQL driven query engine on top of it. Everything that happens on our platform, be it an MFA attempt, a device enrollment, policy changes, role changes, application usage and credential access and more, all are recorded, and as a result, query-able with a standard SQL syntax. Combine that with also being able to query everything we have knowledge of and visibility to (devices, applications, resources, roles, users and groups in Active Directory, etc), and you can build some very powerful reports. Our management web interface provides a means by which you can view these reports, including some we have included by default, but also create them, edit, share and export them. You can even email someone the results of a report within the interface.

reports

 

This reporting data provides another great example of an integration you are  able to combine these reports and data with your knowledge and data about your business, and its activity – i.e. Business Intelligence.  For instance, as your users adopt cloud services like Salesforce, Webex, O365 and others, what does it mean to expose to your management the usage of these services vs. the cost of licenses?

Let’s assume we have a weekly script which is already rolling up a bunch of financial and inventory materials for management – perhaps provisioned machine counts, cloud VM counts, etc.  Let’s add to that an accounting of the number of licenses for Salesforce we actually used (not just paid for!) in the last week.

If we wanted to, we could work out what Salesforce’s license management API is, embed an account in our script and roll up things that way. Though, if we then add Webex we’d have to do the same, with another account for that… and of course, what do we do if the next app down the line doesn’t provide this kind of API. Instead, let’s leverage Centrify’s Identity Service and the platform’s single pane of glass API to get this answer using a consistent SQL query.

First, the query:

select ApplicationName, count(*) as Count from (select distinct ApplicationName, NormalizedUser from event

where EventType = ‘Cloud.Saas.Application.AppLaunch’ and ApplicationName = ‘Salesforce’

and WhenOccurred > datefunc(‘now’, -7)) group by ApplicationName

Note the ease by which we could change things like the range of time, or the application.  It’s not a far stretch to getting reports like, “give me the distinct list of users who used …”

As with our previous example, we could choose any language, but we’ll stick with the PowerShell paradigm for now. We begin by ensuring that this report is run only after MFA requirements have been satisfied:

$token = Centrify-InteractiveLogin-GetToken -Username “your@username” –Endpoint

Then we have but to run the query above using the /redrock/query API:

$restArg = @{}

$restArg.Args = @{}

$restArg.Script = @”

select ApplicationName, count(*) as Count from (select distinct ApplicationName, NormalizedUser from event

where EventType = ‘Cloud.Saas.Application.AppLaunch’

and ApplicationName = ‘Salesforce’

and WhenOccurred > datefunc(‘now’, -7)) group by ApplicationName

“@

$queryResult = Centrify-InvokeREST -Method “/redrock/query” -Endpoint $token.Endpoint -Token $token.BearerToken -ObjectContent $restArg

Having executed the query, the results are now available in $queryResult – for our use case, the Count value from the first (and only) row is what we are after:

$licensesUsed = $queryResult.Results[0].Row.Count

Given this count, we could also do some alerting:

  • Alert if this count is < 90% of the licenses paid for – we’re over spending
  • Alert if this count is > 95% of the licenses paid for – perhaps we need more
  • Track adoption over time, validate departmental or planned moves to new applications

Here you can see I’ve alerted that we’re using far less than the 500 (imaginary) licenses we paid for, so we should find out why. Note the initial MFA using password + SMS too.  All with just barely 30 lines of code.

psexamp

(Note: The entirety of this script is available as part of our free samples)

What Can I Do Using the API?

Really, your imaginapiideasation is the limit. Minor changes to the previous sample’s SQL and you could report on all applications and their usage, or even identify things like users who are using a license but sparingly using an application as a means to freeing up licenses.  The scenarios available are not limited to reporting, or resource creation as shown above either.  Remember, the entire feature surface area is available, things like Cloud User management, automated management of User/Password applications, validating adoption/deployment of mobile applications you’re paying for, or alerting on adoption of applications you’ve banned, retrieving information for inclusion in other automation (SIEM!), protecting your own internal apps and automation with MFA just like privilege escalation in CSS, and anything else you can come up with!

Zones, and Rights, and Profiles, and Audit Databases (Oh My!)

Along with this platform approach comes the need to interact with components of our product and data which reside in your Active Directory or within you network. To that end, I want to highlight the availability of both the Centrify DirectAudit SDK and the Centrify DirectManage SDK, which are also available through our developer platform,

Using the DirectAudit SDK, complicated tasks like large database rotation are simplified and automated. Likewise, the DirectManage SDK opens the ability to interact, integrate and automate with all aspects of our Server Suite, including Zone and profile data, rights etc. Whether your integration point be Windows, *nix or some combination of the two, Centrify is here to help you integrate and automate.

Make Your App SAML Aware (Save a Puppy)

Okay, it won’t save a puppy, but Centrify is a firm believer in industry standards for identity and single sign-on (SSO) like SAML. We recognize that application developers, whether working on their internal web based ticket management system, or the next big SaaS application to take the world by storm, want to focus on their application. To that end, our development platform helps keep the focus on the application by leveraging simple, easy to understand toolkits and samples for integrating SAML into an application for SSO:

C# ASP.NET web application? Ruby on Rails? Python? Java? PHP? Choose the technology that works for your application, and then use our API to ensure it is SAML aware and protected by MFA.

Conclusion

As a developer who uses this same set of APIs daily, I am extremely excited to be able to highlight the availability of our developer platform for you as well. I have had the pleasure of seeing customers and partners already adopting and using it, and I look forward to hearing how you make use of it to further secure your users, ease your support overhead and automate away the pitfalls of secure identity management.

To join the Centrify Developer Program, or to find out more about Centrify Developer Program benefits please visit here.