Sample – HealthCare Application Assessment
July 13, 2023The first choice for authentication is AD, then ED and then internal to the application with / SSO.
ACIS/Cerner
This application is a candidate to keep its local ID store and utilize Enterprise SSO for authentication.
Users must login to Citrix and then the application, which make it a good candidate for SSO to decrease logins.
Roles and authorization are imbedded into the product, so authorization must remain internal. Still need to see about directory sync option?
Business Objects
This application is a candidate to use the ED for authentication.
This application could also use AD after the domain collapse. Roles and authorization are imbedded into the product.
Corporate AD
This application is a candidate to use AD for authentication using Vendor SSO, as it already does. RSA and AD provide all authorization as well.
This application currently uses custom attribute in AD for authentication.
The structure of groups is already migrated and set up in the Corporate AD and the Portal servers are located in CORPAD.
This application would be able to use identity data from the ED to enhance user experience and provide more personalized information through the employee portal.
Kronos T&A
This application is a candidate to use the ED for authentication or AD after the domain collapse is complete. Roles and authorization are imbedded into the product.
Modifications will be necessary to remove customizations that were made to authenticate to multiple domains.
Kronos Visionware
This application is a candidate to use the ED for authentication, but only after JOAs are included.
The roles and authorization are imbedded into the product.
This may require a type of federation solution before the application can use the ED because the user base has a lot of JOA users.
If we treat the two AD forests as authoritative, then we can create users in ED / ADAM.
Lawson
This application will be the source of record for most identity data. It may be able to consume some data (i.e. office phone, email, etc) from other sources.
Authentication could be externalized into ADAM after the upgrade to LSF9. Directory sync is most important to begin with.
This is a good candidate for PCNS. Still need to determine if it requires its own ADAM instance or if it can use the ED instance?
Meditech
This application is a candidate to keep its local ID store and utilize Enterprise SSO for authentication.
Roles and authorization are imbedded into the product. Each MBO could use AD after the collapse, but conversion effort would be required.
PACS
This application is a candidate to use the ED for authentication.
Application Matrix
| Application | Current Identity Store | Type of Users | Current Authentication Method | Can we Externalize Authentication? | Can we Externalize Authorization? |
| ACIS/Cerner | Oracle | Employees, Contractors | Citrix and Internal | No | No |
| Business Objects | Enterprise Authentication (internal) | Employees | Internal | Yes1 | No |
| CORPAD | AD | Employees, Contractors, JOAs | AD/RSA | Yes2 | Yes |
| Kronos T&A | Oracle | Employees | AD | Yes3 | No |
| Kronos Visionware | Oracle | Employees, Contractors, JOAs | Internal | Yes4 | No |
| Lawson | SunOne | Employees, Contractors | LDAP | Yes5 | No |
| Meditech | Magic | Employees, Contractors | Internal | Yes6 | No |
| PACS | ? | Employees, Contractors Temporary employees | AD | Yes7 | No |
- LDAP and multiple other options. AD must be 1 domain.
- Already authenticates against AD.
- Customizations currently in place to work with multi domains. After collapse, customizations will need to be removed.
- Can only use AD after collapse or all users are in ED.
- This currently uses LDAP, will use ADAM after upgrade to LSF9.
- Conversions would be necessary – high effort.
- Currently uses AD(?)