Survey Strategy and Goals

The intent of this survey is to collect information from higher ed institutions about their current strategies for dealing with test accounts/identities, and what gap(s) they see between the tools they currently have at their disposal and what would meet their needs. Security is becoming more and more of an issue in how we test our applications and systems. The aim of our survey is to collect the current state of affairs and also the good ideas of our colleagues, and then share the results of the survey and perhaps spark some discussion about various testing strategies, and determine if there is a way in which MACE-DIR could help support these strategies.

If you would like, we can keep your responses anonymous - just check the box at the end of the survey. Survey results will be made public.

Survey Draft

  1. Identity management departments at Higher Ed institutions have many different ways to provide testing accounts and identities for their application developers. These range from "just test in production" to more complex strategies. Can you please describe how your institution approaches this problem?
    • Our application developers test with our production identity environment and we don't have a separate test identity environment.
    • We have a test environment that is a complete copy of our production identities.
    • We have a test environment that consists only of randomly generated identities and does not contain any real identity information.
    • Other (comment box)
  2. If you have a separate test identity environment, are all developers on campus allowed to use it or is it limited to the developers in your central IT department?
    • Central IT only
    • All of campus
    • Depends on the application and/or the developer
    • Don't have a separate test environment
    • (comment box)
  3. Sometimes problems or bugs arise which can only be solved in the production environment. How does your institution handle this type of situation?
    • We will allow a developer to "take over" someone else's identity.
    • We create a separate, new identity in production for the developer to use. (please describe)
    • We allow a developer to alter their own identity in order to do their troubleshooting (or we will do this for the developer) - e.g. change their type from staff to student. (please describe)
    • We have a "set" of identities in production that developers can use. (please describe)
    • Other (comment box)
  4. If your institution allows test accounts in the production environment, what governance is used:
    • What authority decides a test account in production should be created? (comment box)
    • Is the test credential in production restricted by the same security measures as production accounts (password change, password strength, etc)?
      • Yes
      • No
      • Other, please describe (comment box)
    • are test accounts in production audited or monitored by information security to reduce risk of abuse or misuse?
      • Yes
      • No
      • Other, please describe (comment box)
    • are test accounts in production limited in scope to:
      • particular applications
      • all institution hosted apps
      • not restricted at all
      • Comment box
    • To reduce the number of them, are test accounts in production shared by departments?
      • Yes
      • No, limited to individuals
      • Other (comment box)
  5. Many application developers use their desktops for initial development, then move on to a test environment, and then move on to production. Do you provide any special identities for the "development" environment (as opposed to "test" and "production")?
    • Yes (please describe)
    • No
    • Other (comment box)
  6. At least one institution has created a "test" attribute in their production directory which is used to indicate that an entry is not a real identity. Do you think it would be useful to have an attribute like that available as part of the eduperson schema?
    • Yes, we would use something like that.
    • No, we probably wouldn't be interested.
    • Comments
  7. What doesn't work about your current test environment?
    • Comment box
  8. Would you like your survey answers kept anonymous?
    • Yes, please do not associate them with me or my institution
    • No, it is ok to list my name and institution
  9. Any other comments, ideas or issues you would like to see discussed with respect to identity management test entities?
    • Comment box

Thank you for participating!

  • No labels

1 Comment

  1. University of Alaska has three environments for its central IdM and AuthN functions: TEST, PRE-Production, and PRODuction environments.

    TEST environment is for genuine experimentation, not to be relied on as available or functional; data not maintained.

    PREP environment is for validating proposed changes after initial technical testing in PREP; hardware, software and permissions mirror PROD; data is a snapshot of real data but not actively maintained; system is generally available 24x7 to functional groups for purposes of validation.  PREP may contain accounts for purposes of testing, training, or debugging.  PREP data is generally no more public than PROD data.

    PROD environment changed only after validation in PREP.  Data generally is valid and actively maintained and protected by elaborate role-based ACLs.