IDMS security reference
Authentication
The system utilizes a combination of hosting and application security controls to enforce PKI based mutual authentication. All users must have a PKI credential and be registered with IDMS in order to successfully authenticate.
Layer 1 - Hosting Security: When a connection is made to the application, the hosting server (IIS) will validate that the connection is being made using a PKI based digital certificate. If a certificate is not present, the application will not allow any further communications. If the certificate is present and valid, the transaction is routed to the application layer for further inspection.
Layer 2 - Application Security: After the certificate has been validated by the hosting server, the application will then perform additional validation on the certificate. It will parse the certificate and then perform a look up to to ensure the user has been registered, has a role and is active. All of these validation checks must pass or the application will fail the authentication and the user cannot proceed.
Authorization
IDMS implements a role based authentication model to enable operators to perform their duties while also enforcing separation of duties. As listed in the table below, there are multiple roles within the system that each have specific permissions to perform a set of tasks within the credentialing process. The goal of the role separation is to ensure that no singular person can perform the credentialing process by themselves.
| Role Name | Purpose of role | User State after action |
|---|---|---|
| Requester | This role is permitted to start the process by creating a request for a user. Specifically, the requester can either retrieve a user from an existing data repository (such as active directory) or manually enter the user. After the request is made, the user is in the REQUESTED state. If the requesting officer is also uploading supplemental documentation for the request, the user state is first set to INITIATED. After the documents have been uploaded, the user state is set to REQUESTED. | INITIATED REQUESTED |
| EnrollmentOfficer | This role captures the identity attributes (fingerprints, photo ID details) and identity documents for a given user. This role is allowed to retrieve users that have a valid credential request (users that are in the REQUESTED state). When complete, the user will submit the enrollment package to the web API. | IDACQUIRED |
| ApprovalOfficer | This role will make a decision if the enrolled user can receive a credential. Specifically, this role can retrieve the users in the [IDACQUIRED] state. When this role approves the user, the information is sent to the credential management system. | APPROVED |
| CredentialProducer | This role will print and activate the card. This role can retrieve users in the APPROVED and obtain the photo and other printed items. When the card is printed, set user state to [PRINTED]. Next, when card is bound, set user state to [BOUND] | PRINTED |
| CredentialIssuer | This role will perform a face to face personalization of the credential. The role can users in the APPROVED and obtain the photo and other biographic information necessary to issue a credential. | ISSUED |
| ReportingOfficer | This role is permitted to retrieve credentialing history and system information. | No user state change ability. |
| DerivedApplicant | This role is for general users applying for a derived credential | DPRAPPLIED |
| DerivedRequestOfficer | This role is for operators that are responsible for processing derived credential requests | DPRREQUESTED |
| DerivedApprovalOfficer | This role is for operators that are responsible for approving derived credential requests. | DPRAPPROVED |
| SystemManager | This role is for operators that are responsible for managing users and system configurations. This role has permissions to: add/remove user roles, add/update/remove directories, review system audit logs. | No user state change ability. |
| CryptoDataManager | This role provide the abiilty to apply different cipher suites and keys to encrypted data. | No user state change ability |
| OnDemandCredentialRequestOfficer | This role enables an operator to bind a credential to a user. | No user state change ability. |
Communication protection
The IDMS web API, web page, and client platforms all enforce mutually authenticated, encrypted connections for all transactions.Each transaction is governed and protected by SSL/TLS rules using the strongest cipher suites.