MITREid Connect

From NIEF Wiki
Revision as of 20:18, 22 January 2019 by Jeff.Krug (talk | contribs) (Created page with "This page is a brief introduction to deploying MITREid Connect with support for NIEF Attributes/Claims. ==Deploying== Generally to deploy a customized (customization is pre...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page is a brief introduction to deploying MITREid Connect with support for NIEF Attributes/Claims.


Generally to deploy a customized (customization is pretty much always required outside of test deployments) MITREid Connect does require at a minimum some basic understanding of source control (specifically git), as well as some level of comfort writing Java source code and configuring a Maven project. The information we provide will be light on these details, but will hopefully make sense to anyone already comfortable with these concepts.

Sample Project

GTRI has found the best starting point for deploying MITREid Connect is their LDAP Overlay:

Even if you are not authenticating against an existing LDAP/Active Directory, it may be a good example of how to use the overlay model for your deploy.


Once you have created your own overlay project, you will need to spend sometime adding code to map attributes, add some configuration for your attribute sources, and make sure you enable appropriate data storage mechanisms for your chosen data storage methodology. For simplicity we will focus on the changes you would make to the the specific LDAP overlay example.


There are at least 3 XML configuration files you will need in this directory (they will supercede the versions in the core MITREid Connect build):

  • data-context.xml - This defaults to an in-memory database which is impractical for any longterm deploy as each restart would wipe out any existing trusted partners. While you may be able to simply comment out/in the appropriate data storage, you may also need to configure that storage.
  • server-config.xml - This provides some basic server config (name, logo, url, etc).
  • user-context.xml - This file is where you would put configuration details related to user authentication and admin users, version that comes with the ldap overlay should include some basic LDAP config info.


There are at least 2 Java files that will need to be customized:

  • - If you need any roles beyond users and admins.
  • - You need to edit this file to map LDAP repository data into OIDC Claims.

NIEF Attributes

This is somewhat still a work in progress as there are outstanding TBDs regarding the best practices for encoding NIEF attributes within OIDC Claims. For the sake of documenting the ongoing experimentation, we will simply document the process currently taken to add support for NIEF Attributes. You can find more information about NIEF Attributes within OIDC on the wiki.

Core Code Tweaks

These code changes are already part of the overlay, but similar claims work may require adapting similar files from mitreidconnect, so these details are documented here to note how this can be done outside the overlay as well.


To add a claim you have to edit the following mitreidconnect files:

  • User Info interface: openid-connect-common/src/main/java/org/mitre/openid/connect/model/
  • Default User Info implementation: openid-connect-common/src/main/java/org/mitre/openid/connect/model/


  • ScopeClaim map is in openid-connect-server/src/main/java/org/mitre/openid/connect/service/impl/
    • All claims defined by OIDC are mapped by default to 5 scopes: openid (sub), email, phone, address, and profile. Typically for NIEF we imagine adding a 6th scope of nief.
  • SupportedClaims are in openid-connect-server/src/main/java/org/mitre/discovery/web/
    • You need to update claims supported information available via Discovery.


Within your overlay you will have to write Java code to set the value (and source the value from data stores) for any new claim/attribute you have created. In the example project, the single java source code file that sets the sample NIEF attributes is:


Within the deployed software, if you added a new nief scope, you will need to add support for that scope. This is handled via the web UI (could also presumably be done via direct DB edits).