Skip to end of metadata
Go to start of metadata

Planned feature

This page describes a feature planned for future midPoint versions.

This feature is roughly designed and it was evaluated as feasible. However, there is currently no specific plan when it will be implemented because there is no funding for this development yet. In case that you are interested in supporting development of this feature, please consider activating midPoint Platform subscription.

Motivation

Vast majority of accounts in a typical information system are person accounts. Those accounts belong to and represent physical users of the system. And midPoint is the perfect tool to manage such accounts.

However, not all the accounts are people accounts. There are accounts that represent hard-coded system administration accounts such as root or administrator. Such accounts are sensitive. But usually, there is no big trouble with those accounts. Organizations that follow security best practices are not using those accounts for day-to-day administration. Those accounts are usually reserved for emergency situations. Therefore there is not much need to manage those. The only real concern is to prohibit changes to those accounts. And midPoint has a protected accounts mechanism to make sure those accounts are not changed. That is usually good enough for majority of organizations.

But there is a third type of accounts: service accounts. Those accounts are not used by people. Service accounts are used by services: applications, scripts, integration tools and so on. Those accounts often has elevated privileges. And unlike the hard-coded administration accounts the service accounts are very dynamic. Service accounts change quite often. There may be a need for a new service account if a new application or tool is introduced. Service account password may get exposed and there is a need to change that password. There may be a change in service account privileges when a new version of the application is installed. And finally, when the application lifecycle is over, the service account needs to be deprovisioned. And even more importantly: there should be a process to check if the service account is still needed.

With hundreds or thousands of applications, tools, scripts, integration paths, data pumps, proxies and other elements in your information system it is very difficult to keep track of all the service accounts. But keeping track of accounts is something that IDM systems were designed for.

Service and Accounts

MidPoint implements a concept of services for a several years already. Services are special type of objects and it is possible for accounts to be linked to services in a similar way how accounts are linked to users. Therefore midPoint can already keep track of service accounts. MidPoint can also easily support several account types and therefore it can distinguish service accounts and behave accordingly.

The idea is that a service object in midPoint represents applications, tools, scripts and other components that need service accounts. Service accounts are linked to those service definitions in midPoint. Therefore it will be clear which account belongs to which service (even if the service needs accounts in many systems). The service in midPoint is a very flexible object. It can do almost all of the tricks that user, org and role can. Therefore it may have an owner, its lifecycle can be managed, it may be subject to policy rules and so on. This is a very natural, smooth and extremely powerful way to manage services and service accounts.

However, there are still some limitations and missing pieces:

  • There is a concept of service ownership. This concept is using the same mechanism as role ownership. However, the service-specific processes are not implemented.
    • E.g. there is no process how to distribute new service password to all the owners. Good security policy would be to generate the password randomly (ensuring complexity criteria) and the distribute such random password to owners. So owners would not be able to choose weak password, choose the same password for several services and so on.
    • The process of re-generating the password after the change in ownership is missing.
  • There is no mechanism to prevent accidental changes to service accounts. Of course, service accounts may have different mappings than ordinary accounts. However, as account type (intent) is determined very early in account processing there may be change that mappings from person accounts may be accidentally used on service accounts that are mis-detected.
  • There is an issues with assigning vs linking. Service accounts are often just linked to the services and not assigned. The processes that handle those transitions for service accounts are missing.
  • Service itself can be subject to certification processes. But the process is not tailored specifically for service accounts and there may be missing pieces.

All of this can be improved. Management of service accounts is perfectly aligned with midPoint architecture and design. Just some implementation pieces are missing. And those gaps may be filled in if needed - assuming a funding for this work is provided. MidPoint subscription is the method to provide the funding.

Implementation

Phase 1

There is no need to explicitly mark service accounts in any special way. The concept of intent is good enough. Therefore all the service account will have a service intent. They may be linked to service objects. If there will be no outbound mappings for service intent then the service accounts will not be modified by midPoint. In addition to that we can utilize per-object-type capabilities to disable write capabilities for service intent altogether.

The problem is how to set the service intent. Synchronization code will probably set ordinary intent (default) for all unmatched shadows. However, we need to change this to service intent for those accounts that are (manually) identified as service accounts. Currently (midPoint 3.7-3.8) there is no GUI functionality for this. What is more important is that there is no definition that would specify that default intent may be switched to service intent. The objectSynchronization seems like a good place for this, e.g.:

Therefore the GUI can use this definition to properly render the change owner functionality. In this case the default accounts will have two options to change owner: change owner (user) and change owner (service). The latter option would actually execute two operations: change shadow intent to service and then link the shadow to service object.

Note: there is almost no chance to destroy account data even if intent is mis-detected as long as the account ends up in unmatched situation. In that case the account is not linked therefore no mappings are applied. MidPoint will not change the account unless the account is changed manually from the GUI.

In addition to this there are expected changes in the UI for service objects. There are expected bugfixes and improvements as this part of the UI is rarely used. The projection enforcement mode needs to be applied on a per-object-type basis to resolve the assigning vs linking issue (service accounts will be linked but not assigned). Additional improvements to other part of GUI, meta-roles and other mechanisms may also be needed.

Service account passwords will not be managed in this implementation phase. The passwords may be changed manually from the GUI. But no automatic mechanism will be provided. There will be certification support.

Phase 1 Notes

  • We will implement an expression that could determine kind,intent,situation and owner (and "index" later on).
  • There will be reclassification action that will "reset intent" and run whole kind/intent classification from scratch.
  • The reclassification should be manual or automatic. In phase 1 we only need automatic. There should be some kind of condition that should only reclassify account in "unmatched" situation.
  • For midPoint 3.9 we do not need any GUI functionality. Everything should be automatic.

Later Phases

  • Automated password management and distribution.
  • Re-certification
  • Assignments and legalization (assigning vs linking)

See Also

 

  • No labels