IdentityNow Implementation Requirements Gathering Questionnaire

Requirements Approach / Overview

Leading into implementation, some people may share specific requirements

they have, and others often may not, or may not know how to easily
articulate their requirements with regard to IdentityNow feature sets. This
document is a requirements gathering questionnaire, which is designed for
any implementation personnel to ask questions necessary and gather
information about particular requirements for implementation of
IdentityNow. The idea is that questions in this document can be asked to a
particular implementation, and their responses recorded to better
understand expectations around the implementation.

The resulting answers from this questionnaire should be recorded by any

implementation personnel and written down to trace the project needs, and
guarantee those specific requirements make it into an implementation
design, which follows this document. If there are requirements / items
discovered that are beyond the scope of the project, beyond the scope of
what can be implemented, or what the product can allow, those should be
handled as project issues tracked by the project management staff.

Once final requirements are gathered and signed-off, a technical

implementation design can be drawn up for implementation, and
corresponding testing plans can be mapped to that functionality. Further
discussion around testing may be necessitated beyond what this document
covers.

Project Details

Business / Timelines

This section details requirements and discussion points around how the
project is run and its purpose.

 What are the hard project timelines?

 What are high-level requirements you are trying to achieve with the
implementation?

 What are current project drivers?

  What are the priorities for the project? Are there must-haves?

 What is your change control process?

 What are different groups within the business that might interract with
the system? If so, for what? And whom? e.g. Managers, Security,
Auditors, Help Desk, etc.

Testing

This section details requirements and discussion points around testing.

 What tests are needed to guarantee acceptance?

o User Acceptance Testing (UAT) is commonly what we see;

typically done by the customer or subsidiaries.

 How do we test the implemented functionality?

 Do you have a test environments? How do those map to the sources

or applications in scope?

 Who does the testing? Do you have a dedicated testing team?

 Types of testing needed:

o Unit Testing

o Functional Testing

o Integration Testing

o Quality Assurance (QA)

o User Acceptance Testing (UAT)

o Load / Performance Tesing

 This necessitates another specialized tenant often.

o Penetration Testing

Architecture / Infrastructure

We share our cloud communication architectural diagrams. The customer can

also share their environmental details and any supporting materials. The
customer should be prepared to go over the technical details of their
environment, and this discussion will lead into source configurations in the
next section.

 How many VAs do you anticipate deploying? We recommend 2+ in

Production and Sandbox.

 Do you have any security requirements which may drive the VA

deployment?

o Normal Deployment

o Proxy

o Secure Tunnel

 Do you have any High Availability (HA) or Disaster Recovery (DR)

requirements?

 VA placement:

o Do you intend to put this in a DMZ? (Best Practice: Avoid DMZ

deployments. Refer to Deployment in the DMZ is Not
Recommended.)

 Network toplogies - where will the sources and in relation?

 Ownership:

o Who would carry out the VA deployments?

o What is the process?

o When is the earliest we can deploy these?

o Do we need to do any special coordination?

 Are there any security, audit, or compliance questions or concerns?

Sources / Integrations

In this section, we detail the sources or integrations that we will be

communicating with. This can be a fairly lengthy and details section on its
own, depending on the level of detail you go into.

 What are your Authoritative Source(s)? Or said another way, what are
the data sources that contain your identity information?
 o Typically this is some sort Human Resources (HR) system, but
could be others.

 What are your Non-Authortitative Source(s)?

o Typically this is some sort Human Resources (HR) system, but

could be others.

For each source identify:

 What is the business purpose of the specific system / source we are

connecting to?

 In general, about how many accounts are on this system? How many
accesses / entitlements?

 Who are the source owner(s)?

o Business Owners

o Technical Owners

o Security / Compliance Owners

o Other?

o Who will be our main point of contact for questions?

 What is the overall priority of this system in regards to project scope?

o Is this a must have / high priority, or a nice-to-have / low priority?

 Priority aside, what is the readiness of this system?

o Is it relatively easy to onboard? Is this a 'quick win'?

 What is your provisioning process to this system look like today?

o Is it manual?

o Is it automated? - If so, how?

 What is the intent for this source?

o Read / Aggregations?

o Creating accounts?

o Updating accounts (and access)?

o Deleting accounts (Note: we do not support this currently)

 o Enable / Disable accounts?

o Password management?

 Does this source have test environments?

o If not, how are we going to mitigate risk with the in-scope

features?

 How often do you need to bring in data (aggregations)?

o Are there any Service Level Agreements (SLAs) you have with
the business? How rigid are these?

o Note: We do not do real-time aggregations.

 What are the means (technical or otherwise) to connect to this system?

o For design, refer to our source connector list - located here.

o Note: Start looking for differences in feature support between

the connectors and the requirements.

 What information does the accounts and entitlements house?

o What information in necessary to bring in?

o What information makes an account unique?

 What information may tie an account back to its owning identity? (i.e.
correlation data)

 How do you structure your account data? What does an ideal account
look like? What are the data mappings?

 Are there differences in data across populations?

 Is there anything else to mention about a source that hasn't been

conveyed yet? Other details?

Identity Model

In this section, we detail the various identity populations as a basis for

identity management. This is designed to map the authoritative sources
(already discussed) to how we might build the identities and where we might
get data.

 What type of identities are you bringing in?

 o Are they treated differently? the same?

 Authentication - If these identities were to log into the system, how

would they authenticate?

o Pass-Through Authentication to a source (e.g. Active Directory)

o Integrated Windows Authentication (IWA)?

o SAML

 For each identity, are there specific information / attributes you want to
collect?

o This is the interesting 'things' we can say about an identity.

o Spreadsheet of these?

o Are there are any calculated attributes?

o Where do these attributes come from?

o What is necessary by downstream systems?

o Should we transform, map, or normalize attributes? Do you have

inconsistent or bad data?

o How should we handle special characters? e.g. dashes in names,

accents, etc.

 Note: IdentityNow can handle these accented and special

attributes just fine, as we store everything in UTF-8.

 What should we use for first and last name? The legal name? Or
preferred name? e.g. Robert Smith vs Bob Smith

 Do you have a manager hierarchy defined? What source(s) determine

this?

o Does anyone not have a manager? If so, what ar ethe

implications of that?

 Overall identifier - is there an overall username construct?

o How will they login?

o We use this as a 'uid' in IdentityNow.

 What is an identity's lifecycle today?

 o Joiner / Create

o Leaver / Disable

 Are there any attributes which describe an identity's status / state?

o This will be the identity's Lifecycle State attribute.

o e.g. start and end date, HR status code, or a combination?

 How does your authoritative source(s) handle:

o Rehires?

o Transfers?

o Conversions (i.e. from Contractor to Employee)

o Leave of Absence (LoA)

 Is there possibility for multiple HR records for a single identity?

o i.e leave and come back? Or should we handle this as seperate

identities?

IdentityNow Features

In this section, we should validate the features they have purchased, and
which they want to implement. This will determine which specific feature
requirements we discuss in next sections. Only go through specific sections
as needed, or required.

 Do you have any specific order or priority of features you would like to
implement in a certain order?

o Note: We can make recommendations in ordering and priorities.

Provisioning

This section will detail requirements around provisioning. This can

sometimes be a longer conversation than the questions here, depending on
their expectations, and needs. It is a good idea to document as much as you
can.

 By what means, automated or manual, are you doing provisioning

today? How can this be improved / changed?
 o Is IdentityNow a replacement or a supplement to these tools?

o Are there other solutions that provision?

 What is your overall provisioning process today? How do you setup

accounts? What is the process - walk through it.

o Give a 'day in the life' example - for instance, a joiner.

 What are the sources for provisioning?

o Refer to the sources list.

 When is someone first given access? X days before start? On the day
they start? As needed?

 What access to we typically grant for your identities? (Note: This is a

very loaded question)

o Do you have mappings of access

o Do you have existing role definitions in your systems today?

 Identity Lifecycle Revisit - Automated Process - What happens when

someone is hired? terminated? other?

o Enable of accounts?

o Disable of accounts?

o Send emails?

o Grant access?

o Remove access?

 Is there any manual override to automated processes? Describe how

that works?

 What are the sources we're provisioning to? (Refer to sources

mentioned earlier and add if not there)

o What operations do we need to support? Create, Update, Enable,

Disable, (Delete)

o What is a template or "gold standard" for creating this account?

How do you do this today?

o What is username we generate, and how is this generated?

  Common Patterns: first.last, filast, etc.

 Is it unqiue? What do we about special chars?

Incrementation schedule? i.e. what happens if somethign
isn't unqiues.

o Sequencing of account creation (e.g. AD first, AzureAD second,

etc.)

 Do you have anything defined today for roles?

o Access granted, assignment critieria, ownership

 Are there any simple packages or patterns of access that you can
easily grant?

 Are there specific attributes that you want to enforce across the
sources?

o Are there any write-back to authoritative sources?

 Discuss the password generation and transmittal best practices.

 Are there any other provisioning requirements that haven't been

covered so far?

Access Request

This section will detail requirements around access request. Most of the time
this is a supplement to provisioning (above). This can sometimes be a longer
conversation than the questions here, depending on their expectations, and
needs. It is a good idea to document as much as you can.

 By what means, automated or manual, are you doing access request

today? How can this be improved / changed?

o Is IdentityNow a replacement or a supplement to these tools?

o Are there other solutions that are requesting access?

 What are the sources for access request?

o Refer to the sources list.

 Request process

o Do you allow self-service request (i.e. request for self)?

 o Do you allow for request on behalf of (e.g. manager requesting
for an employee)?

 If so, who can request on behalf of someone else?

 Requestable items

o What items to you allow to be requestable?

o Do you have a good understanding of these accesses? Has this

been defined?

o How do you present these to the end-user? Do you have nice

language / descriptions defined?

 Approval Processes

o What are the common approval processes that you follow?

o Do all accesses have the same approval process?

o Are there access that have no approvals?

 Are there any other access request requirements that haven't been
covered so far?

Certifications

This section will detail requirements around access review / certifications.

This can sometimes be a longer conversation than the questions here,
depending on their expectations, and needs. It is a good idea to document
as much as you can.

 By what means, automated or manual, are you doing certification

today? How can this be improved / changed?

o Is IdentityNow a replacement or a supplement to these tools?

o Are there other solutions that are certifying / reviewing access?

 Do you have any auditing findings? Or deadlines you need to meet?

 How frequently do you certify?

 What are the sources for access review / certification?

o Refer to the sources list (above).

  What type of certifications?

o Manager

o Source Owner

o Entitlement Owner

o Ad-hoc via Search

o Other?

 What are the contents and people in certification (Campaign Filters)?

o Who are the certifiers? Who owns them?

o Is there anyone you don't want to certify (Campaign Filters)?

o Is there any delegation to others (Campaign Reassignment)?

o A good example of this is executive certifications may be

reassigned to their executive assistant.

 Do you have any need to group entitlements together (Access

Profiles)?

 Manager Certs: Do you have manager heirarchy defined?

o Make sure manager is a proper reference

 Source Certs: Do you have source owners?

 Entitlement Descriptions? Do you have these? Can you get them? Are
they already part of group description?

 Reporting

o What is required by audit?

o What is required by operations?

 Are there any other certification requirements that haven't been

covered so far?

Password Management

This section will detail requirements around password management. This

can sometimes be a longer conversation than the questions here, depending
on their expectations, and needs. It is a good idea to document as much as
you can.

 By what means, automated or manual, are you doing password

management today? How can this be improved / changed?

o Is IdentityNow a replacement or a supplement to these tools?

o Are there other solutions that are changing passwords?

 What are the sources for password management?

o Refer to the sources list.

 What password flows / use cases are you using?

o Authenticated (Change my password)

o Unauthenticated (Forgot my password)

 Are any passwords synchronized together?

o If so, do all passwords conform to a single password policy?

 Are the password policies consistent or different across systems?

 Are there other integrations needed?

o Desktop Password Reset (DPR) - Explain use cases here, if

needed.

 Do users need to be authenticated on the network?

o Password Interceptor (PWI) - Explain use cases here, if needed.

 Do DCs have ability to call IDN directly? Or via proxy?

 Strong Authentication - What are methods used?

o KBA - What the questions that you need? How many? Do these
need to be multi-lingual?

o SMS / Text - Mobile or Phone

o Voice - Mobile or Phone

o Integrations

 Duo

 RSA
  Symantec

 SafeNet

 Do you need password reminders enabled?

o This is only available for certain sources (like Active Directory),

which have a password reset date.

 How are notifications sent out? What do these look like?

 Are there any other password management requirements that haven't

been covered so far?

Platform / System Settings

This section will detail requirements around miscellaneous system settings.

Branding

 Do you have specific colors or logos we can use with the product?

 Do these need to be targeted towards a certain sub-set of identities?

Email

 Do you have any specific email template formats needed?