gsa / ficam-arch Goto Github PK
View Code? Open in Web Editor NEWThis is the old location for the FICAM Architecture. New location below.
Home Page: https://playbooks.idmanagement.gov/arch/
License: Other
This is the old location for the FICAM Architecture. New location below.
Home Page: https://playbooks.idmanagement.gov/arch/
License: Other
/services
broken links (404 errors)
reported by colleagues at State (thank you!)
links under main page for /ficam-arch/services/ return 404
http://gsa.github.io/ficam-arch/applications/
ficam-arch/pages/ficam_applications.md
I think we should add another view to the Applications Diagrams.
Former is built to scale horizontally, with features meant for workflows, auditing, lots of integration points, etc.
The latter is built to scale vertically - one or two types of users, all the same, same information, same processes, higher volume of users.
From an Applications Diagram standpoint, you do want to keep them separate (separate IAM solution architectures, development approaches, and deployment).
Update styles and template to use USWDS 2.x
Old, old version of USWDS (0.9?) currently in use
https://designsystem.digital.gov/
This is a medium effort.
The navigation (sub and side) and all assets in _includes need to reference newer styles. Clean assets, etc.
The FICAM Services Architecture does not include clear guidance on Access Certification/Attestation. As part of the CDM Phase 2 SailPoint deployment participating agencies now have access to the tools necessary to streamline this process and increase efficiencies and accuracy.
The SailPoint IdentityIQ Unified Governance Platform and Compliance Manager is being installed as the solution for the Master User Record. Compliance Manager enables agencies to;
Identity Warehouse and Resource Connectors
Policy Model
Role Model
Risk Model
Data-driven Workflow Engine
Business-friendly Access Certifications
Automated Policy Management
Audit Reporting and Analytics
DHS CDM Master User Record (MUR) Functional Description
SailPoint will support the development of the necessary content
It reflects us, our subconsciousness and our reality, a regular formatted reality.
The Universal Laws of Observation
"Only in Darkness (False, non-communication)
do you understand the Light (True, communication)."
"It is each and everyone`s own responsibility to evolve."
"You cannot imagine, the imaginary unknown of the Almighty Unknown."
(Binary-coded quantum-philosophy)
The Existence,
(m)-personification, in (m)-personation.
“If and only if existence. In nature, nature is existence. Existence is nature, nature in existence. Is, if (in)-personation is existence… (m) -personification. “The Many” is existence, the Gamma-universe extension.”
A realist stance in quantum-philosophy. Super-galactic science.
Epistemic vs Ontic phenomenology.
Auto-epistemic expansion, known propositional logic and quantum mechanics.
Goal 1.2 in the Diagram states:
Enable Agencies to establish and manage prove, trusted identities for all system users
Should be:
Enable Agencies to establish and manage proven, trusted identities for all system users
Step 6 is the capture of biometric modalities. This step is performed after the steps for the validation of the identity is performed. This assumes that the validation of the identity can we done with a government issued ID and additional information provided, such as an account number.
I'm a first time contributor, so I will try to fill this out as best as I can.
The last step in LOA4 is the capture of biometric modalities to increase the level of non-repudiation. There is a practice in many countries where a government agency has biometric information of its citizens and is capable of providing biometric comprisson services to validate the identity of a person, and sometimes a national ID is issued. We should be aiming at this goal. Currently, that agency doesn't exist in the US, but we can use other agency to perform the same task. Additionally, there are identitiy sources that can be used to perform this same task. So, instead of verifying a government issued ID or an account number only, we can include the biometric verification of the identity.
Additionally, the governement agency itself can perform a biometric identification (1:N search) to reduce the possibility of having duplicated identity records. This task, deduplication of digital identity records, should be mandatory for LOA4. This is closely related to use case 5, as a match result to avoid deduplication should include the resolution of a possible biometric match.
https://arch.idmanagement.gov/usecases/14_proofidentityloa4/
New content recomendation.
Use case 4 should have biometric data captured in step 3.
Use case 4 should have biometric data verification in step 4.
Use case 4 should have a new step 5 for biometric identification, internal and external, to avoid DIR duplication. This would replace the current step 5 for confirmation, and move it to step 6.
Use case 4 should have a new step 6 for confirmation. This would replace the current step 6 for biometric capture. The current step 6 for biometric capture should be eliminated.
Expeted outcomes.
An increased level of assurance on the identities managed by the system. Additional features to verify identities.
I would recomend a similar analysis for use case 8.
Received June 2019 - a federal agency comment for updating identity management service definitions
Item | Current Text | Recommended Change | Change | Rationale |
---|---|---|---|---|
Identity Management | Identity Management is the set of practices that allow an organization to establish, maintain, and terminate identities. | Identity Management is the set of practices that allow an organization to establish, maintain, and terminate digital identities. | Add "digital" before "identities". | Ensure no misunderstanding by casual readers of something ICAM practitioners take for granted. |
Identity Proofing | Verifying information to establish the identity of a person or entity. | Verifying information to establish the identity of an entity. | Change "a person or entity" to "an entity". | Entity covers both persons and non-persons. |
Creation | Establishing a digital identity composed of attributes that define a person or entity. | Establishing a digital identity composed of attributes that define an entity. | Change "a person or entity" to "an entity". | Entity covers both persons and non-persons |
Identity Maintenance | Maintaining accurate and current attributes within an identity record over its life cycle. | Maintaining accurate and current attributes within an identity record over its lifecycle. | 1) Change title to "Identity Maintenance" 2) Change "life cycle" to "lifecycle" | 1) The title should be descriptive enough that it can stand alone 2) Lifecycle is usually written as one word in this context |
Identity Resolution | Finding and connecting disparate identity records for the same person or entity. | Finding and connecting disparate identity records for the entity. | Delete "person or". | Entity covers both persons and non-persons. |
Deactivation | Deactivating or removing an identity record. | none |
Received June 2019 - a federal agency comment for updating identity management service definitions
Item | Current Text | Recommended Change | Change | Rationale |
---|---|---|---|---|
Sponsorship | Formally establishing that a person or entity requires a credential. | Formally establishing that an entity requires a credential. | Change "a person or entity" to "an entity". | Entity covers both persons and non-persons. |
-- | -- | -- | -- | -- |
Registration | Collecting the information needed from a person or entity to issue them [sic] a credential. | Collecting the information needed from an entity to issue that entity a credential. | 1) Change "person or entity" to "an entity" 2) Change "them" to "that entity" | 1) Entity covers both persons and non-persons. 2) "Them" is plural yet the object referred to is singular. |
Issuance | Transferring a credential to a person or entity. | Providing and/or binding a credential to an entity. | 1) Change "Transferring" to "Providing and/or binding". 2) Change "a person or entity" to "an entity". | 1) Credentials are not always 'transferred' and recognition of the credential binding to an entity or entity persons may be needed for relationship assurance. 2) Entity covers both persons and non-persons. |
Credential Maintenance | Maintaining a credential over its life cycle. | Maintaining a credential over its lifecycle. | 1) Change title to "Credential Maintenance" 2) Change "life cycle" to "lifecycle" | 1) The title should be descriptive enough that it can stand alone 2) Lifecycle is usually written as one word in this context |
Revocation | Withdrawing a credential from a person or entity. | Withdrawing a credential from an entity. | Change "a person or entity" to "an entity" | 1) Entity covers both persons and non-persons. |
Alternative comments to #143
http://gsa.github.io/ficam-arch/businessprocess/
ficam-arch/pages/ficam_business_process.md
The image itself contains the header words ("The diagram below...")
I think it might be more useful to remove the header words, put those in the body of the page, along with key (federal entities, business partners, customers) - and let the diagram just be the visual element.
This way agencies or consumers can use the visual element and add their own words if they want to reuse.
Thoughts
Can I be added to the repository so I can clone it down to my laptop? Or is web only the policy?
Thanks,
Steve Howard
(I work in GSA IT, Office of the CTO. I am submitting this as part of our work to ensure GSA complies with the new Federal Source Code Policy.)
GSA needs to create an inventory of all agency source code, whether open source or closed source. The inventory we create will appear on Code.gov. The inventory will contain basic information about each source code repository, but will not include the source code itself. Please read the implementation guide and use it to submit this repository to the inventory by December 5.
Basically, please do one of the following, the details of which are described in the implementation guide:
.codeinventory.yml
or .codeinventory.json
) to this repository (optionally, use this tool to generate a metadata file)Let me know if you would like me to open a PR with an example .codeinventory.yml
file.
Please let me know if you have any questions.
Thanks!
References:
Auditing & Reporting covers the oversight of ICAM programs, but is silent on logging entity actions. Where should that go?
Use AMP or ANDI to perform automated and manual 508 tests.
Top Issues
1 | Avoid use of placeholder values to label or explain input
2 | Ensure headers and cells are properly associated
3 | Ensure the language of a document is set
4 | Ensure ARIA regions, landmarks and HTML sections are identifiable
5 | Ensure links or controls that open new windows or frames do not open without a warning
Test test
Where should risk accounted for? NIST 800-63-3 expands and encourages using measures that inform risk-based authentication and authorization decisions, but the closest connection is Credential Bridging, which covers only AALs and only for federated issuers.
Maybe risk is covered under Policy Administration but I think it should be more explicit. A related issue is Trust, which must be in Federation, as it applies to the confidence in partners and their ICAM processes.
The links in the Standards and Policies will need updates.
Some of the document links are outdated, some point to the wrong repositories (OMB memoranda), and some links are broken.
https://arch.idmanagement.gov/standards/
The updates to the links will be provided.
Verify that the links that are updated with new ones.
https://github.com/GSA/ficam-arch/blob/staging/pages/ficam_standards_policies.md
I recommend:
Rationale: Absent the above, the document is problematic to cite to -- not only for research purposes, but also for pointing to in standards/policy documents and contracting instruments / agreements.
For example, agreements may point to the document as reflecting a common understanding on a particular date. If the document is constantly changing without a versioning or document history record, agreeing parties might find it difficult to determine agreed to terms that were present on the date of the agreement -- absent github training. Such training is likely too much of an ask for the target audience.
Use case #20 [Accept Credentials in a Federation] should be revisited to use terms consistent with NIST 800-63-3. Note that “validate” and “verify” appear to be used interchangeably. Also, “verification assertion” is not a NIST 800-63C term. This flow is not what’s portrayed in the user case overview, although I appreciate that you can’t show all of the detail.
Submitted for Jim Thomson, via email July 6, 2018
ficam-arch/_services/12_credentials.md
update to align with consumer identity playbook, remove unnecessary words, add change anything in parentheses
Subcategory names should be unique and identifiable if they stand apart from their category title. Thus Creation should be Identity Creation, Maintenance should be Identity Maintenance (and Credential Maintenance). The others, such as [Credential] Issuance can at least be inferred.
The content contained in the Template.md pages (and their locations in the directory structures) is not consistent across the FICAM-Arch, FPKI-Guides, and PIV-Guides repos.
https://github.com/GSA/ficam-arch/blob/staging/template.md
https://github.com/GSA/fpki-guides/blob/staging/template.md
https://github.com/GSA/fpki-guides/blob/staging/pages/template.md
https://github.com/GSA/piv-guides/blob/staging/pages/template.md
None.
I'm proposing simplifying the Descriptions on the FEA alignment diagram (http://gsa.github.io/ficam-arch/index.html).
Diagram -> Simplified Description
I'm reviewing content for Plain Language principles, and proposing alternate language: http://www.plainlanguage.gov/howto/quickreference/checklist.cfm
Is there documentation, plan, schedule for Derived PIV life-cycle federal support?
If an agency wants to enable DPIV for their mobile devices and apps, where can it turn for DPIV life-cycle support like PIV life-cycle support. Any planning work? Any scheduled support?
https://arch.idmanagement.gov/usecases/24_createderivedpiv/
There is no search feature in the FICAM Arch Guides.
Add a search box to FICAM Arch Guides and post the data to search.usa.gov. The feature will be similar to the one provided at idmanagement.gov.
Should be added to the navbar.html and it will be included in all pages. Possibly replace the "View this site's code" button on the top navigation.
New search box in FICAM Arch Guides website.
Received June 2019 - a federal agency comment for updating federation service definitions
Item | Current Text | Recommended Change | Change | Rationale |
---|---|---|---|---|
Attribute Exchange | Discovering and sharing identity attributes between different systems to promote interoperability and simplify the process for establishing an identity. | Discovering and cquiring identity attributes between different systems to promote interoperability. | 1) Change "sharing" to "acquiring". 2) Delete "and simplify the process for establishing an identity." | 1) "acquiring" is a better word, since attribute exchange is rarely bidirectional for a given identity. 2) Deleted "Establishing an identity" since it is a design decision (either because the software won't work w/o a directory record, or for caching, or for audit, but they aren't the point of exchanging attributes. |
Credential Translation | Transforming a token or credential into an alternative format, potentially containing claims about the client, for acceptance at a relying party. | Transforming a token or credential into an alternative format, potentially containing claims about the entity, for acceptance at a resource. | 1) Change client" to "entity 2) Change Relying Party" to "resource" | 1) Should not introduce new term "client" when it's not needed at this high level 2) This was only occurrence of Relying Party. Also, should use limited set of terms. |
Credential Bridging | Establishing a cross-certified, affiliated relationship to trust credentials at a level of assurance asserted by those credentials. | none | ||
Policy Alignment | Establishing a mutual relationship between parties by deliberately establishing common standards and principles. | Establishing relationships and a common understanding between parties through use of authoritative policies, standards, principles, and authorities. | 1) Delete "mutual" and make "relationships" plural 2) Add "and a common understanding" 3) Change "by deliberately establishing" to "through use of" 4) Add "authoritative policies" and "authorities". | 1) Word choice 2) Add the purpose of the relationship 3) Better words; "deliberately" is peculiar choice 4) To be inclusive, a broader set of policies and authorities in addition to standards and principles |
In reference to the NIST SP 800-63-3 document, is there a time-frame when the official FICAM document will be updated?
I'm not sure if this qualifies as an issue, rather than a comment, but the Business Process Diagram (which is great!) should define LOA.
Recommend that the main categories, Identity Management, Credential Management, Access Management, Federation, and Governance also have brief descriptions, as the subcategories do.
Include information from FICAM v2.0 Section 12 (part B)
Current states in diagram:
Automate information discover and access across the Federal Government in all security domains
Should be?
Automate information discovery and access across the Federal Government in all security domains
Use Case #15 [Grant Access to a Protected Resource] should be updated for Assurance Levels consistent with NIST 800-63-3
Submitted for Jim Thomson, from email July 6, 2018
We talked about this briefly before. We should incorporate Secure Token Services (STS) and other derived credential capabilities.
In looking at the Create and Issue Derived PIV (http://gsa.github.io/ficam-arch/usecases/24_createderivedpiv/) use case, there is a scenario where an STS from a trusted network could obviate the need for a mobile device. An example would be the STS leveraging Windows authentication on a trusted environment to establish a derived PIV. Conceptually, this would be an Identity Provider acting on behalf of the individual and an STS is an operational example.
Received June 2019 - a federal agency comment for updating identity management service definitions
Item | Current Text | Recommended Change | Change | Rationale |
---|---|---|---|---|
Policy Administration | Creating and maintaining the rule sets that govern access to protected resources. | Creating, maintaining and distributing digital policies that govern access to information resources. | 1) Add "and distributing" 2) Change "rule sets" to "digital policies" 3) Change 'protected' to 'information' | 1) Distribution of policies should also be included here 2) Digital policies is a more inclusive term than rule sets 3) Better word for this level of detail |
Entitlement Management | Establishing and maintaining the authoritative access permissions for a person or entity. | Establishing and maintaining the authoritative access permissions for an entity. | Change "a person or entity" to "an entity". | 1) Entity covers both persons and non-persons Question [for FICAM]: What's the difference between Entitlement Management and Provisioning? What's the difference between an entitlement and an attribute and an access permission? |
Provisioning | Linking and unlinking access permissions for a person or entity to a protected resource. | Opportune associating and dis-associating authorization attributes to entities to provide for access to and use of information resources. | Rewrite | Question [for FICAM]: What's the difference between Entitlement Management and Provisioning? 1) "Opportune" is unnecessary and confusing as to its intent |
Authentication | Verifying that a claimed identity is genuine based on valid credentials. | Verifying that a claimed identity's validity based on trusted credentials is genuine with a measurable level of assurance. | 1) Change "identity is genuine" to "identity's validity" 2) Change "valid" to "trusted" 3) Add "is genuine with a measurable level of assurance" | 1) Subtlety about whether authentication checks the validity of the credential or the claimed identity 2) Credentials must be trusted not only at the point of authentication, but in asserting authentication across boundaries. 3) Credentials must provide a measurable level of assurance so needed levels of trust can be leveraged commensurate with the environment and the activity for which authentication is needed. |
Authorization | Granting or denying access requests to protected resources based on a policy determination. | Granting or denying entity access requests to information resources based on determination by a digital policy. | 1) Add "entity" 2) Change "protected" to "information" 3) Change "policy determination" to "determination by a digital policy" | 1) Attribute the access to an entity 2) Better word 3) Clarity |
We are proposing changing a URI (/applications to /components)
If we make this change and there are embedded links in other docs, we should include an updated/custom 404 as well
It doesn't seem like we added a custom 404 yet to this repo.
Simple example: https://github.com/GSA/fpki-guides/blob/staging/404.md
Federalist guide for custom 404's: https://federalist.18f.gov/documentation/customization/
The use case overview at https://arch.idmanagement.gov/usecases/ conflates credential federation and authentication federation. Item 20 and Item 16 should never be in the same path. That is, if “Access” is applying credential federation, then Item 20 is superfluous because an external (federated) user is presenting a credential directly to Access. On the other hand, if authentication federation is applied, Item 16 is superfluous because an accepted authentication assertion is conveyed from Item 20 to Items 17/18.
Submitted for Jim Thomson from email, July 6 2018
https://arch.idmanagement.gov/usecases/
Use cases 16 and 20
Updates to content requested
Issuance begins with “Transferring a credential to a person …”. The verb seems odd since normally credentials are created and assigned (i.e. issued) to persons.
Under Federation, should Credential Bridging be first, since generally authentication precedes creating assertions or exchanging attributes?
Open for discussion
Where should the alignment be with the IDESG Functional Areas?
Governance would be an easy one.
One of the challenges I see is that we are Services framework focused, while the IDESG core documents are Functional model focused.
At a minimum, we should align terms?
There is too much overlap between Entitlement Management and Provisioning. The former includes “maintaining … permissions for a person …” and the latter includes “Linking and unlinking access permissions for a person …”? Is that not maintaining? Is there a clearer boundary between these two or should they be combined?
Let's have a vote? 👍
Training
Not a computer geek
?
Expected Outcomes: ####
Received June 2019 - a federal agency comment for updating governance service definitions
Comments:
Item | Current Text | Recommended Change | Change | Rationale |
---|---|---|---|---|
Enterprise Governance | Developing and implementing the policies, rules, and procedures to manage and improve an ICAM program. | none | ||
Auditing & Reporting | Monitoring, reviewing, and reporting on an ICAM program's conformance with rules, policies, and requirements. | none | ||
Redress | Fixing problems and vulnerabilities that occur during standard operation of an ICAM program. | Mitigating risks, threats, and vulnerabilities that occur during operation of an ICAM program. | 1) Change "Fixing" to "Mitigating" 2) Change "problems" to "risks, threats" | 1) Mitigation is broader than "fixing" and recognizes cannot always eliminate vulnerabilities 2) Risks and threats are broader than "problems". |
Recovery | Preparing the procedures and assets that would be needed to recover from a security or privacy breach and ensure continuity or service. | Preparing the procedures and assets needed to recover from failures or breaches associated with ICAM to ensure the security and continuity of service. | 1) Change "a security or privacy breach" to "failures or breaches" 2) Add "associated with ICAM" 3) Add "the security and" | 1) Recovery responsibilities must address more than just breaches 2) Limit scope to ICAM 3) Scope must include more than continuity of service |
Conceptual overview and Services framework are using different color schemes and wording
One intent from the working group was to synthesize the I, C, AM areas and show clear alignment from one artifact to the next
/imgs/
ficam-arch/pages/ficam_conceptual.md
ficam-arch/_services/overview_services.md
ficam-arch/_services/*
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.