...
| Expand | ||
|---|---|---|
| ||
Why? When your users connect to infrastructures and services, the services will need to identify the users as belonging to your group. And as you work together across sectors, you will want users with the same name but from different communities to work together. Similarly, if you use a shared AAI provider, for example based on the Snctfi guidelines, also there your collaboration should not be mixed up with others. Recommendation: use a name that is almost certain to be unique globally, and pick a name that is not prone to changes, avoiding project naming for instance. The domain name system (DNS) is a good starting point, for example "he3epp.nikhef.nl" for a national collaboration for studying the 3He(e,e'pp) reaction at Nikhef, or "atlas.cern" for the global ATLAS collaboration located at CERN. Note that while the domains should be permanently assigned, you don't necessarily need a web site or email addresses with this domain. Uniqueness is enough. By using a DNS name, it fits easily in the 'scope' component of many AAI protocols like OpenID Connect and SAML. Applicable guidance: AARC-G069, PDK Membership Management guidance |
...
| Expand | ||
|---|---|---|
| ||
Why? While management of the user directory, or responding to compromised credentials and questions from your service providers may appear a technical task, these often involve decisions that deal with your 'primary assets': the research data you work with, the processes that keep your community together and wholesome. A handful of people working together can solve issues that arise in an ad-hoc fashion, but as soon as you grow a bit further, structured communication becomes essential. "Why was I suspended?" "Why can't I join your group ... you have a service I need (and by the way, I just want to use it, not contribute)?". You need a body to take up that authority. Unfortunately, the AAI is often the first time you hit these hard questions! Recommendation: A principal investigator, research group chair, or faculty dean makes a good starting point for a governance body. If your community becomes larger, write down rules of participation, draft a memorandum of understanding, or have a written collaboration agreement in place. Often there is already something in place. Many public research projects demand having a collaboration or grant agreement in place. There is usually a governance structure in there, which can be re-used here. No need to re-invent the wheel within your community. Applicable guidance: governance as such is out of scope of the PDK, but look at your project agreements, department model, or grant office to find a suitable and effective solution. |
...
- Define the purpose of your collaboration (this will be used for your AUP)
- We strongly suggest
- Identifying your primary assets
- Completing a risk assessment
- Adopting the REFEDS Data Protection Code of Conduct if it is suitable for your research collaboration
- Defining your rules of participation and the escalation procedure in case of non-compliance
- Any additional legal and regulatory compliance necessary
- Define, or agree to adopt as is, the following 6 documents and seek endorsement from the governance body
Expand title view the 6 documents Membership management
Privacy Policy
AAOPS
Security Operational Baseline
Incident response procedure
Membership Management - Review the AEGIS endorsed policy guidelines required for AARC compliance and ensure their technical implementation
- Identify your assurance requirements following https://aarc-community.org/guidelines/aarc-g031/
- Identify suitable token lifetimes https://aarc-community.org/guidelines/aarc-g081/
- Ensure that the policies are presented to and accepted by the relevant audiences
- Publish your documents and responsible parties at a suitable location
...