Implementing an Authentication and Authorisation Infrastructure (AAI) that is compliant with the AARC Blueprint Architecture (BPA) requires navigating a range of technical, policy, and organisational decisions. This section provides practical guidance for prospective implementers - whether you are a research community, infrastructure operator, or service provider - based on maturity level, available resources, and interoperability goals.

Step 1: Define Your Research Community's Requirements

Before choosing an architecture or software stack, clarify:

• User Base: Who are your users? Are they affiliated with institutions in eduGAIN, external (e.g. guest, citizen science), or a mix?
  
• Access Requirements: Does the sensitivity of your research require additional access approval mechanisms? Do you need fine-grained access control, or is basic authentication sufficient?
  
• Scale: How many services do you plan to connect to your AAI? Which protocols do they require? What is a realistic estimate of effort required to migrate all users and services from one AAI to another in case of a crisis?
  
• Existing Infrastructure: Do you have an identity provider (IdP) or group management service already?
  
• Sustainability: Can you commit operational resources, or do you need a hosted service? For how long will your AAI be required? Will your available support level be able to increase with growth of participating institutes or services?
  
• Environment specific requirements: Do you need any physical connectivity to dedicated networks? Are IT interventions restricted to fixed time windows? Do you have any other unusual requirements that may not be supported by off the shelf solutions?
  
• Governance: Who will take responsibility for policy decisions regarding your AAI? Do they have enough authority over your research community to make high level statements and decisions, e.g. for data protection, security policy requirement etc?

Step 2: Define your Policies 

Further guidelines are provided in the policy section. For practical steps for adopting AARC's policy recommendations, please visit the Policy Development Kit.  

Step 3: Choose an Implementation Path

The following flow chart may help you frame the necessary questions to understand whether to use a hosted AAI platform or run your own.

Option 1: Complete AAI Platform, hosted by a third party supplier 

Wherever possible, the AARC community recommends using a hosted platform to benefit from the points mentioned previously. 

• Use Cases: University collaborations in fixed duration projects, temporary research endeavors,  research collaborations with limited technical staff. Please see later sections for examples of hosted solutions.
  
• Pros: Faster deployment and configuration, AARC compliance out of the box, integration with eduGAIN
  
• Cons: Less flexibility for local policy enforcement or custom attribute handling
  

Visit the section on existing hosted services.

Option 2: Self-Hosted Proxy Architecture

Ideal for communities needing more control over attributes, group management, or federation strategy. May be more suitable for communities that already operate an internal AAI and are seeking to interoperate with the wider community. 

• Use Cases: Certain conditions may require a research community to host their own AAI such as; network connectivity requirements (i.e. connecting to a protected physical network for experiment operations), having full control over the release cycle (i.e. needing to only upgrade at certain times of year to align with research needs) or to mitigate the cost of a future migration (migrating from an AAI to another can be a very slow process and you may choose to host your own AAI to mitigate the risk of migrating high numbers of services). 
• Pros: Full flexibility, modular architecture, greater control over hosting location and update schedule
• Cons: Requires DevOps expertise and maintenance; policy coordination across proxies can be complex; higher costs

Visit the section on existing software solutions and ensure AARC Compliance with Technical Guidelines.

Step 4: Plan for Operations and Sustainability

• Staffing: Assign roles for technical ops, security, policy coordination, and user support. Ensure adequate personnel are in place for technical assistance.
  
• Monitoring: Track login flows, token issuance, and service usage
  
• Updates: Stay aligned with emerging AARC TREE recommendations (e.g. support for OIDC Federation, digital wallets)
  
• Governance: Ensure stakeholders agree on responsibilities, especially if federating across institutions or countries
• Funding: Secure ongoing resources (vs. project-based funding) for operational continuity.