Page tree

Requirements gathering  form for the AARC Project.

 

The purpose of this survey is to expand the set of requirements and use cases that the user communities and research infrastructures have for AAI.

If your community has already produced a similar document with the same topics (AAI requirements), please provide a link to the document and focus on the questions that have not been answered, and the new developments not included in the referenced document.

The questions will cover the technical requirements to design the architecture, but also requirements for outreach and dissemination activities within AARC, to make these activities more effective.

Part 1: Short and high level description of the use case

Please, provide a short and high level description of the use cases of the community you represent.


Part 2: Current AAI status of your community/research infrastructure

What is the current experience with AAI of your community?

Has your community/research infrastructure already uses AAI
solutions for their use case?

  • What benefits do you see for Federated Access?
  • What barriers do you see in joining a federation? [1]
    • The Management doesn’t consider that important
    • No enough funds/resources
    • Lack of technical knowledge
    • It is unclear how to organise an Identity Management (IdM)
    • It is unclear if the IdM should be internally or externally done
    • There is no clarity in the organization about the benefits of using an IdM
    • We already have an IdM but it is not completely compatible with SAML/OpenID or other industry-standards
    • Too much bureaucracy to join a federation
    • Other
  • What is the user experience in the interaction with the available AAI solutions? 1
    • Expectations fulfillment
    • User friendliness
    • Quality of service delivered by the tools

How the penetration of AAI in your community can be improved?

Do you think that your organization is lacking in information about federated identity management?

 

What material do you need to inform your organization about federated access? Do you see the need for trainings to better inform representatives of members in your research area? [2]

  • If your organization isn’t part of a federation yet, what can be helpful in order to join one? For example:

      -More informative material for management and decision makers
      -Technical personnel dedicated to IdM
      -Guides and trainings on how to implement an IdM and an Identity Provider
      -Something ready that can be already used (like Virtual Machines)
      -More resources
      -External technical support
      -A simpler procedure to follow for joining
      -Other

What are the technical solutions adopted?

  • Can you describe the solutions you have adopted highlighting as applicable:
    • Technology or technologies adopted:
      • X509
      • SAML2
      • OpenID Connect/OAuth2
      • OpenID
      • Kerberos
    • Identity Providers (IdP) federations integrated (e.g. eduGAIN) or:
      • Approximate number of individual IdPs integrated
      • Approximate number of users
    • Solution for homeless users (users without a federated insitutional IdP)
    • Solutions to handle user attributes
       

Part 3: Requirements for federated AAI

Which type of Identity Providers are relevant for your community?

Which IdPs your users would use?

  • Their institutional IdP, part of national federations and eduGAIN.
  • Non federated institutional IdPs
  • Research community catch-all IdP
  • Social media

 

What are the preferred authentication technology?

What are the requirements for the authentication technologies to be used in your use cases?

  • User friendliness, single sign on (SSO)
  • Web browser and non-browser applications support
  • Support multiple technologies and credential translation services (e.g. SAML -> X509 translation)
  • Support for delegation (e.g. execute complex workflows on behalf of the user)

 

Could your community  benefit from Scalable IdP attribute release policies?

In your use case, do you foresee the need to get attributes (e.g. institution, email address, name,…) from the IdP of the user? If the users will use many different IdPs, coming from different institutions, the service providers supporting the community need to access these attributes, therefore there is need for a set of policies that make scalable the negotiation between SPs and IdPs.

Do your community need persistent identifier for users ?

Do you foresee for your use cases the need to have a persistent identifier to be associated to user’s identity? Supporting a persistent identifier allows the users to more easily change IdP preserving their identity.

Is the support for different level of assurance relevant for your use cases?

Different LoA, allow users to use credentials with different level of assurance, and communicate properly the information to the service providers about the LoA of the used credential.

If yes, whom can we contact to ask further questions on your LoA needs? There is a dedicated task in AARC that investigates LoA.

Does your community need community level authorization?

Authorization is separated from authentication and it is controlled by the community. To implement this community-driven authorization user communities must manage a set of attributes associated to the users, which need to be provided to the service providers together with the identity attributes provided by the IdP.

How is the current coverage of IdP federations?

Are the current identity federations (e.g. IGTF or eduGAIN) covering enough identity providers/institutions to be a feasible option for your users? What are the use cases where the coverage is not sufficient to reach all the involved users?

 

Other requirements

Please, feel free to add more requirements or topics to be discussed within the AARC project.


[1] This question will provide inputs to the dissemination and training activities.

[2] This question will provide inputs to the dissemination and training activities.