Identity Management for Application Owners

You might find this article helpful if you are the owner of an Elanco application. 

IAM stands for Identity and Access Management.  IAM is used for securely storing (encryption) and managing user identities, and what access permissions they have. IAM ensures that users are who they say they are (authentication) and that they can access the applications and resources they have permission to use (authorization).  

What does our new IAM solution look like?

Our new IAM stack consists of a few different pieces of technology: 

1. Workday is a software vendor of cloud-based ERP that allows us to manage our workforce data. Workday gives a way to oversee time tracking, procurement, employee data, financial accounting, and expense management at anytime and anywhere. This is where we maintain employee information, and this feeds in to: 
2. RSA Identity Governance and Lifecycle (IGL) simplifies how access is governed and streamlines how access is requested and fulfilled. The solution helps mitigate risk and make sure we continue to be compliant by managing groups, provisions and deprovisions of accounts based on the rules we have defined and feeds login data into: 
3. Active Directory provides authentication and authorizes all users and computers in a Windows domain type network—assigning and enforcing security policies for all computers and installing or updating software for on-prem services (Lives in the Colo) 
4. Azure AD which provides directory services for applications running in the azure cloud and can be extended to provide SSO services using modern auth protocols. Azure AD is fed by Active Directory  

Workday is the only place where Elanco employee data will be entered/updated manually. RSA is a locked box which only receives data and then feeds it out based on a set of rules which we define. When data is fed in from Workday, RSA generates a few details (based on our rules) e.g. generates a user’s email address and returns this to Workday. It then provides the users login data on to Active Directory. But no one will ever access RSA directly to update/edit anything. 

The rules in RSA can be applied automatically following specific events from Workday. This means there are some efficiency savings to be had. User access can be permitted and revoked based on location, role or level, as people join, leave and move through Elanco.  At the most basic use case, this means no longer having to ask an admin to manually maintain email distribution lists, teams and groups.  

I need to manage my own groups though!

There will still be a capability which allows users to create and manage their own specialist groups where these cannot be automated based on attributes, however we don’t have full details on what this will look like just yet. We’re aiming to design a process which is no more work than the way we currently consume Group Manager. As with all work streams, we’re aiming to strike a good balance between proper governance and security, and user experience. 

It’s also worth noting as we shift to consuming more Microsoft services, the associated O365 groups should be self-managed, giving group owners the ability to self-manage access to forms, distributions lists and Power Platform dashboards. 

Are we nearly there yet?

Not quite! This is the desired end state. However, as we are divesting, we’re in an awkward phase with multiple data sources. Workday isn’t live until November, so it’s not ready for it to be our only source of truth about our workforce just yet. We also haven’t quite finished testing the rest of the IAM solution. So, for now, Lilly manages data about our workforce and provides our identity allowing us access to the Lilly IT environment. This does mean we need to match data across the Elanco/Lilly network divide, so that Workday can feed other systems which are going live. 

 

We’re managing this in the interim by getting an export of specific workforce data from Lilly, doing some cleansing, and loading this into Workday. We’ll not need to introduce Elanco user data into the IAM system until November 2019. 

To understand what is changing, it helps to have an understanding of some data attributes used in identity. Each Elanco employee, has several different pieces of information associated with them, these are either allocated to them, or generated from other attributes, 

• Username/ID: The data item which user’s log in to some systems using e.g. in Lilly for some systems we us a number like C123456 
• UPN: This is the User Principle Name; in Lilly this is the user’s name in email address form e.g. joss_joanna@elanco.com   
• Primary SMTP Address: This is your reply to email address 
• Email alias: This applies if you have requested to change your email address e.g. If I requested to change my email from joss_joanna@elanco.com to jo.joss@elanco.com. I can use Jo.Joss@elanco.com to send and receive emails (as it’s set as my primary SMTP address) but I can still receive mail if people try to contact me at joss_joanna@elanco.com. The exchange server (the post office sorting office for email) just knows that I also go by an alias. 

So, what’s changing?

We want to take this opportunity to standardise on the way people login to our systems. In Lilly, some applications require an email address to login, some require a system ID, and some which require your UPN. In Elanco we want to simplify this, in line with the rest of the O365 experience and with industry standards. Users will have one method of logging in – their ID – in the format: firstname.lastname. Email addresses will all be standardised to be firstname.lastname@elanco.com but don’t worry, those aliases will still work too so you’ll still get your emails! 

Of course, we will continue to drive toward Passwordless; Windows Hello will be enabled on devices meaning Fingerprint or Face ID can be used. Hopefully meaning less forgotten passwords! Once logged in with Windows Hello, if you use browser like Microsoft Edge or Chrome this will even log you into some of the services you need too. That’s even less mouse clicks to get started! Put simply, we want to bring some order and standardisation to identity in Elanco and make it easier for users to get on with their working day!  

There will likely be some users who need to access applications in the new Elanco before the users themselves have been migrated.  They’ll be in the unique position of needing to know their new identity ahead of time, but fortunately most people won’t need to worry about this piece until they get their new device. 

What does this mean for the migration?

Well, it’s complicated. We’re hoping that BinaryTree (Find out more here) will help us with a lot of the technical capabilities we will need to make the migration a success, including the email rewriting/spoofing. If the POC is successful, this process should see us through to the end of the TSA. Our current challenge is how we will go about mapping the Lilly data source attributes to the Elanco environment through Binary tree. We’re currently looking for common data attributes to make this happen.  

And there’s the small matter of changes to SSO which will affect owners of applications. 

How can I prepare my application for SSO in the new Elanco?

You’ll have some work to do. 

If your application currently uses modern authentication methods, and you are just doing a “lift and shift” to Elanco, this might be as simple:  

1. Ensuring that you are using the correct attribute as UPN
2. Application owners will need to recreate their security groups in Elanco’s RSA by raising a service request in our new ServiceNow catalogue. We’re still working through what this piece looks like but we’re aiming to design a process which is no more work than that of the experience we currently experience using Group Manager. 
3. Once the group has been set up, application owners will raise a service request to our MSP HCL to get the relevant JSON/XML export to use with their app. This will allow the application to work with SSO using a modern authentication method like SAML or OAuth.  

 

If your application currently uses legacy authentication methods (e.g. LDAP, Kerberos), this might be more complicated.  Given the number of different ways applications consume legacy authentication methods, it isn’t possible to address every variation in this post. Solutioning will?depend on the type of application, and any vendor support available for modernisation.? This could be as simple as adding a modern auth module to a web app (and following the above process), or as complex as rebuilding the way the application functions.? 

 But here are a few things that we’ve been thinking about: 

• Applications which have been migrated will no longer be able to use the system ID as part of the login, as this won’t exist in our data model.  Legacy authentication protocols often have sensitive methods of logging in – if you change the attribute order of the data source, this can quickly break the mechanism. 
• There are some solutions which can act mimic compatibility with legacy authentication e.g. Microsoft App Proxy, but these are not a panacea for every use case. 
• If your application is hardcoded with a hostname/IP address this may be problematic. When the infrastructure changes and that hostname/IP changes, this is going to break your SSO.  
• If your application is currently hardwired into a domain controller, consider if your site will be provisioned a domain controller in future (Hint: Manufacturing sites usually will)  However, if in future you will no longer have a domain controller you will need to update your application to access a controller over the network instead of on premise. 

 

I’m an application owner, how long have a I got?

Lilly SSO is available until the end of the TSA. Elanco SSO should be production ready in November 2019 when we have introduced workforce data into the IAM solution.   

How can I get more help?

We’ll be releasing more technical guidance as soon as we can, some areas where we appreciate more information is needed: 

• What authentication will look like at a service level, and how it can be consumed 
• More information about the Global Identity Repository (GIR) 
• Which modern authentication methods will be supported  
• A set of patterns to aid decision making for applications owners needing to modernise their authentication methods. 

Please, (Please, please!) remember to put your application on the Master Application Collection List spreadsheet and include the authentication method in the details. If you don’t know the exact authentication method that your application uses, then provide any details that you can! Without a clear picture of what authentication methods the different applications are using, it’s impossible to produce helpful guidance.