This project has moved and is read-only. For the latest updates, please go here.


The Open Immunize IMS may operate a series of services spread across multiple load-balanced servers. In order to communicate authentication information (known as a Security Principal) between requests and servers, Open Immunize leverages claims based tokens.

In this architecture an access control service (ACS) receives token requests from a client application. Such token requests contain information for which the client is requesting authorization. This can include:

  • User authentication information such as User Name and Password
  • The device credentials from the physical device the user is using
  • The application credentials from the app the user is using
  • Claims the user is making which it is requesting the ACS to verify such as:
    • Purpose of the request (purpose of use)
    • Organizational information such as org unit
    • Policies for which the user is requesting override


After validating this information the ACS will issue a new token (SAML, SWT, JWT, etc.) which it signs with a private key. The ACS may attach other claims to the token such as expiry time, issue time, policies for which the principal is allowed access.

The client interface then uses this bearer token to communicate with other IMS services such as FHIR, etc. The token may is validated using the ACS’ public key. The IMS can then perform further operations including restricting access to full or partial resources.


Last edited Jan 13, 2016 at 8:56 PM by jf03cg, version 2