- Protecting Consolidated Data on Engineered Systems
- K-12 and Cloud considerations
- Oracle Solutions supporting ICAM deployments
- Oracle Open World / Public Sector / Identity Platform
- NASCIO Releases Updated State Identity Credential Access Management (SICAM) Documentation
- Database Security: The Need for a Comprehensive Strategy
- Taking the fear out of a Cloud initiative through the use of security tools
- Reducing SPAM on Identity Registration Services
- SICAM: Privacy and the Golden Record
- SICAM: SICAM Component Architecture
Thursday Oct 27, 2011
Saturday Sep 03, 2011
By Paul Laurent on Sep 03, 2011
When I first started contributing State Identity Credential Access Management (SICAM) content last year, I didn’t get too far into the discussion before trying to spell out what the key value props are for organizations heading down that path. Meeting conditional funding requirements, complying with state/federal mandates, eliminating benefits fraud, streamlining process…all those initiatives benefit from SICAM’s single, trusted view of identity. That notion of a “single view of the individual”, that “this Jane Doe is the right Jane Doe, the same Jane Doe as I look from system to system and department to department”, is sometimes referred to as the “Golden Record” for that person. The need for data quality and identity resolution makes Master Data Management (MDM) a necessary component in a SICAM architecture.
Figure: SICAM Component Architecture
The component architecture is really born more out of policy requirements than technology dependencies. Taking one more look at my comments on Public Sector policy drivers for SICAM, we can see how each of these components works into the mix:
- MDM provides the aforementioned identity resolution, data quality, and single-view of individuals (in many ways like a primary key/foreign key relationship, only here between systems and identity repositories.)
- Once we understand our relationship to (or “single view” of) an individual we leverage any number of Credentialing techniques to communicate and assure that relationship in the form of a token or artifact.[i] Depending on the level of trust in any given identity, or required for authentication, different credentials (certificates, smart cards, one time passwords, knowledge based authentication, etc.) can provide different levels of identity assurance that scale to the different security needs and requirements of grant initiatives, compliance mandates, and reporting specifications.
- Identity and Access Management tools manage and honor those identities and credentials in a manner that allows interoperability across systems and domains without impeding their use in systems of origin.
- Service Oriented Architecture (SOA) provides the common standards and infrastructure for rapid deployment and consumption of interoperable services across departments, agencies, states, municipalities, etc.
- One of the primary drivers for adopting a SICAM infrastructure is to enable a collaborative Business Intelligence reporting platform.[ii] SICAM acts as an interoperability layer that allows departments to report on (often regulated and sensitive) data without co-mingling and sharing of raw backend data that would violate compliance mandates and law.[iii]
- And finally a Portal Interface for presentation.
Typically my writings are on the Identity Management and Security side of the SICAM equation, but over the next couple of posts I’d like to delve into some important discussions around the MDM area of the component architecture. Recently I’ve had several great discussions in the field around the legal, privacy, and security ramifications of the MDM/Identity Resolution piece of SICAM that are worth sharing. With this discussion of SICAM components as background, I’ll delve in next time with some frequent questions and considerations around the care and feeding of the “SICAM Golden Record.”
[ii] See data sharing and reporting requirements for initiatives like Education’s State Longitudinal Data Systems (SLDS) grants and Health and Human Service’s National Health Information Network (NHIN)
[iii] Again, drawing from SLDS and NHIN, student performance data and personal health information are strictly regulated by the Family Educational Rights and Privacy Act (FERPA) and the Health Information Technology for Economic and Clinical Health Act (HITECH, see also HIPAA) respectively.
Monday Jun 27, 2011
By Paul Laurent on Jun 27, 2011
Thursday Jun 09, 2011
By Paul Laurent on Jun 09, 2011
Monday Oct 11, 2010
By Paul Laurent on Oct 11, 2010
Identity and Access Management topics related to Federal, State and Local government agencies