Date: Thu, 28 Mar 2024 09:54:01 +0000 (UTC) Message-ID: <88792553.5979.1711619641995@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5978_1851150782.1711619641995" ------=_Part_5978_1851150782.1711619641995 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
2. Reporting and Auditing
What current and historica= l data is maintained for reporting?
Is the reason (automatic a= nd manually approved) for all provisioning decisions and actions stored? Ca= n it be sent to an external system (Splunk, logstash, etc) data warehouse?<= /span>
How is the data stored? Ca= n it be read by external systems?
Can we export the data in = its entirety?
Can we control how long th= e data is maintained?
Does this product provide = what our auditors and compliance officers need?
Does this product provide = what our application (target system) owners need?
Reporting (should we just = combine audit and report?)
What pre-built reports= are available? Can they be customized?
Can we build our own r= eports? Using a GUI? Non-GUI?
Does the product suppo= rt reports on
Access for an applicat= ion (target system)
All access for a user,= all users in a unit, all users for a supervisor
Elevated or high-risk = access
Separation of Duties= span>
What output formats ar= e available for reports (eg, PDF, CSV, HTML)
Is the data used for r= eports available for use by third-party reporting tools?
Can reports be run on = a schedule and sent by email or to a (possibly external) report repository,= and/or made available via GUI? If available via GUI, what are the access c= ontrols?
Auditing
Can we compare intende= d provisioning to the actual state of an application on demand?
<= /li>Does the product audit= changes made within it (eg, who made a change to group membership logic wh= en, and what the change was)
Does the product suppo= rt Separation of Duties audits?
(If you do access revi= ews / attestations) does the product provide adequate support?
= li>review by person, unit= , application
review of only manuall= y-decided access, exceptions only, etc
Can audit results incl= ude =E2=80=9Ccomments=E2=80=9D (eg, =E2=80=9Caccess being removed because = =E2=80=A6=E2=80=9D) that become part of the record
Can the auditing work = with an external ticketing system (eg, ServiceNow, Remedy)
How does the product d= efine and schedule reviews, notify and remind reviewers, etc? Can the produ= ct send emails and/or use an external ticketing system? Are reviews done wi= thin the product, or in a document sent to the reviewer?
How does the reviewer = to report results? Is the effort required proportional to the number of cha= nges?
Does the product suppo= rt workflows, logic, etc. needed to implement access changes determined by = a review?
Notes from a subsequent discussion on identity matching, need to work th= is in.
where does a person start (eg= , HR, or self-service from person registry)
match methodology (scoring, e= tc), is match process in person registry, or one or more of the authoritati= ve systems
processes for handling dups, = possible matches (in registry, systems of record, and possible downstream s= ystems)
HR, Admissions, IAM responsib= ilities
are social ids involved? Do y= ou need a match-social-id-to-person-in-registry process?
do sponsored (loosely-affilia= ted) & contractors use the same processes?
is an external identity servi= ce involved?
Tom: Identity matching is a r= egistry function - receiving person data from multiple sources. Do other in= stitutions see it as a different function?
Ethan - person registry is al= so a source of record at UNC
Is the person registry/identi= ty matching part of provisioning or something that happens before?= p>
One of the competencies that = a person registry needs to have is identity matching, whether it=E2=80=99s = part of the provisioning infrastructure or upstream
How centralized is the instit= ution=E2=80=99s ERP
May want to survey BTAA about= scoring systems and matching rules - there may be a variety
Karen - incoming students wil= l use a guest account in the person registry and will link it to their inst= itutional identity
Tom - Madison is thinking abo= ut models where there=E2=80=99s a low bar for creating a profile (that has = an institutional or social credential associated). When a user establishes = a role (student enrollment, employment, etc), we can provide the role owner= (registrar, HR) a mechanism to bind the role to the user=E2=80=99s profile= , or we can use the fact that the role was established via an authenticated= session with the user=E2=80=99s profile to bind the role to the user. &nbs= p;(Tom and Jon have been pondering ways to "prove" the logged-in session, s= ince we have historical issues with sources guessing at identifiers instead= of resolving them in a login.)
Identity matching is not =E2= =80=98one size fits all,=E2=80=99 but may be part of the provisioning proce= ss. Need to add to the identity provisioning portion of the survey= p>
5. Credential provisioning
a. &nb= sp; Password rules and policies
= i. Describe the password policies you support with regard to co= mplexity, length, and any dictionary checks. Include character classes supp= orted in complexity checks. (Call nist
ii. Does = your product support flexible password policy based on password length? For= example support pass phrases but requiring additional character sets for s= horter passwords.
= iii. Describe your support for passwords in multiple languages.=
= iv. Describe your products support for password expiration, inc= luding any support for flexible expiration based on grouping, assurance, or= other factors such as password quality.
= v. Describe how your product conveys password quality to end us= ers.
= vi. Describe how you product meets accessibility guidelines
b. &nb= sp; Initial password setting (credential activation?= , initial login?)
= i. Describe how your product assures initial password setting i= s being done by the appropriate authority, such as invitations, one time an= d/or short lived tokens etc.
= ii. Describe your products support for terms of use and informe= d consent when getting a credential.
= iii. What platforms are supported for end user devices setting = initial and subsequent passwords, including any required technologies.
= iv. Describe any features your product has to deter attacks on = unclaimed credentials.
= v. Describe how your product handles multiple credential stores= .
c. &nb= sp; Assignment of additional authentication factors<= /span>
= i. Describe your support for certificate based authentication.<= /span>
= ii. Describe your support for multifactor enrollment, specifyin= g supported technologies and products, explicitly address U2F support.
= iii. Describe any support you have for challenge response quest= ions.
= iv. Describe any unlisted additional authentication factors, an= d any features that help user recognition such as image validation.<= /p>
= v. How do you handle loss of a (perhaps only) two factor device= , such as one time tokens
d. &nb= sp; Deprovisioning of credentials
= i. Describe the states supported by your product for credential= s, such as open, expired, disabled, locked/unlocked, security deny, etc.
= ii. Describe any workflow available for deprovisioning, time ba= sed, approval based, and any attribute or membership checks that can be use= d for deprovisioning workflow.
= iii. Describe any controls for sanity checks in your product to= prevent accidental mass deprovisioning.
= iv. Describe the administrative capabilities your product has f= or deprovisioning and deprovisioning intervention, include any delegation f= eatures.
= v. Describe how your product handles deprovisioning of credenti= als w/r/t propagation to multiple credential stores.
In addition to the above, include doc= umentation of your APIs related to all of the above functional areas.
6. Target Directories and Service Provisioning
Linking identities bet= ween directories or services
Describe how your prod= uct links an identity in a source directory to the same identity in the tar= get (and service?)
Are your user linkage = attributes characterized as follows:
Immutable
Static
Globally unique
=What is the process of= account matching if accounts already exist?
How flexible is custom= ization of the IDM connector that provisions the account?
Communicating updates = to target directories
Describe the transport= mechanism used for updating target directories and services
What protocols does yo= ur product support for provisioning of accounts (for example, SOAP/REST, LD= AP, Messaging, JDBC)
What supported standar= ds can your product use? (e.g., SCIM, LDIF, SPML, etc.)
Describe how your prod= uct batches or queues large quantities of updates.
Provisioning models: w= hen to provision
Describe how your prod= uct supports =E2=80=9CJust-in-Time=E2=80=9D provisioning model-- on demand = provisioning when the user logs in.
Describe how you suppo= rt the =E2=80=9CJust-in-Case=E2=80=9D provisioning model-- pre-provisioning= accounts en masse
Workflow-based provisi= oning model
Describe how your product = handles automated workflows.
Describe how your product = handles manual intervention by an admin.
Describe how your product = supports end-user self-service workflows.
Do you support a thres= hold to alert for large quantity of updates?
Reconciliation<= /p>
How does your product = ensure the target directory or service has state in sync with the source?= span>
Does your product supp= ort rollback or transaction?
Fine-grained authoriza= tion
Describe what authoriz= ation sources your product supports (e.g., Grouper, LDAP, Active Directory)=
Is the same mechanism = for account provisioning used for authorization provisioning?
What protocols for tra= nsmitting authorization does your product support? (e.g., Messaging, SOAP/R= EST, LDAP, JDBC)
What supported standar= ds can your product use for authorization? (e.g., SCIM, LDIF, SPML, etc.)= span>
Does your product allo= w support for custom or proprietary interfaces for authorization?
How does your product = links or maps internal groups and roles to external service-level fine-grai= ned authorizations?
Deprovisioning and rep= atriation
Describe how your prod= uct triggers deprovisioning of identities in a target directory or service.=
Describe the process o= f deprovisioning identities in a target directory or service.
How is authorization r= emoval handled for deprovisioned users?
Describe how your prod= uct supports repatriating a service account from institutional to personal.=
Do you support a thres= hold to alert for large quantity of changes?
8. Groups and roles
Types of groups=
Describe how your prod= uct supports a list of definable groups.
Describe how your prod= uct supports a hierarchy of groups (i.e., nesting and relationships between= groups)
What entities can be membe= rs of groups?
?? What upstream data = sources does your product readily support?
Do you support sets of= groups associated together? (i.e., base, exceptions, includes/excludes)
Administration<= /p>
Describe delegated acc= ess administration features for group management.
How does your product = deal with =E2=80=9Corphaned=E2=80=9D delegation? (When previous admins are = no longer there.)
Do you provide APIs th= at would allow an external group and access management tool to drive your p= roduct=E2=80=99s groups and group memberships
Do you support attribu= te-based (ABAC) or role-based (RBAC) concepts to drive groups and group mem= bership?
Can groups have permis= sions associated with them?
What sort of attribute= s or metadata about groups are available?
Does your product supp= ort automatic review of roles/groups (attestation)?
Guidance for architect= ing
How does your product = expose or link groups or roles for fine-grained service authorizations?
How do you support Att= ribute-based access control?
How do you support Rol= e-based access control?
Are roles managed within t= he product?
How does your product = define a default role or template (set of groups) for new entities?<= /p>
How are groups updated= /kept in sync?
Describe synchronizati= on mechanisms, i.e., changelog vs. full sync
10. Product Cost/Vendor Considerations
Licence