PUHURI is a resource allocation system for compute services. It also provides reporting and access management to compute services.
LUMI is the main user of PUHURI services. PUHURI exploring expansion for other use cases such as for quantum and for national HPC systems (Karolina?).
2. Which field of science are you serving ? (Frascati manual of Fields of Research and Development (FORD)) (can we compile a list!?)
Puhuri serves any field of science. Covering all sciences.
3. Please provide description about the research infrastructure (e.g. which kind of instrastructure and related services are delivered and by whoom, is there a formalised collaboration etc.)
Puhuri as a broker for resource allocation for allocation bodies. They can be EuroHPC, National allocation committees and local resource allocators.
The architecture and services provided are described at https://puhuri.io/architecture
Puhuri is currently running as a project funded by NeIC and is developed and operated as collaboration of Sigma 2 (.no), DeIC (.dk), NAIC (.se), Etais (.es), CSC (.fi), Uni of Iceland (.is), and observers SUNET(.se). There is an ongoing process to handover the puhuri system to a permanent host.
5. Please provide description of the user audience - type of users (research, citizen scientists, industry users), number of users, distribution over the globe and organisations
Users are any eligible users accessing the HPCs connected to the PUHURI.
With LUMI being the main user atm, most of the users are researchers coming through the national allocators in LUMI consortium https://www.lumi-supercomputer.eu/lumi-consortium/ . EuroHPC is also an allocator in the system. Industry users and citizen scientists are also in scope. Currently, users are coming mostly from the LUMI consortium countries, but the user base is global. Currently there is more then 7000 users who have accessed LUMI.
Using MyAccessID.
6. Is the RI member of European Open Science Cloud (EOSC)?
Puhuri is not, but the RIs connected to PUHURI most likely are.
7. Is the RI participating in Citizen Science Programmes or other initiatives or programmes?
Puhuri is not, but the RIs connected to PUHURI could be.
(probaly 2 sets of question based on the BPA knowledge level - BPA begineer/rookie vs BPA savvy/advanced user)
.se
1.Describe the currently running solution for authentication and authorisation infrastructure (AAI).( Which specific authentication methods being used to cater for different user audience (e.g Institutional accounts (eduGAIN), ORCID, Social media, Others - please specify))Puhuri uses MyAccessID as identity layer. It uses eduGAIN IdPs and other specific community IdPs that are connected to MyAccessID. It also uses eIDs (eIDAS1.0) and recommends eduid.se as a last resort IdP. ORCID is making things complicated.
No Social media ids used, as users typically need to be identified at REFEDS LoAEach medium or high for access to HPC resources.
On top of that, Puhuri offers a resource allocation services that implements specific access control rights for connected HPC services, that result for the resource allocation process.
2.Is your AAI solution compliant to AARC BPA (blueprint architecture)?
Yes, as MyAccessID is used as the identity layer.
3.Which AARC guidelines are you implementing? (add the table... )
Yes, based on AARC guidelines implemented by MyAccessID Marina Adomeit TO CHECK!
(introduction material needed to present BPA and the guidelines)
4.What is your comments about BPA implementation? (challenges in implementation, challenges in clarity, technical difficulties etc.)
NA - question should be asked to MyAccessID
1.Does the Research Infrastructures have an access policy? (the access policy governs who can access the infrastructure, under what conditions)
Puhuri does not have an access policy itself. Each Allocation body and corresponding HPC system using Puhuri has their own access policy. In addition MyAccessID has an access policy as well.
From users perspective, they will see two Terms of Use - one from MyAccessID and second from HPC system they are accessing.
2. Is there a formalised procedure to manage access rights to services (e.g. cooperation agreement, call for application and evaluation, ad-hoc individual order/access, member of an organisation, etc.)?
Puhuri does not, but the HPC services connected to puhuri implement their procedures to manage access rights. The procedure for managing access rights for HPC is typically through calls for application and evaluation which are done on based on the national procedures. Which ever procedures allocation bodies use, Puhuri will collect the information regarding the allocations and the corresponding access rights.
Puhuri is at the moment also building an review and allocation portal, that will be offered to service owners and allocation bodies to perform the call for applications and review process.
3. How do you implement the policy for access management (e.g. how is the individual who can access the research research data/measurement data/your research instrument identified and authorised)?
First of users need to be eligible to apply for the resources, and then they will be granted access if the proposed project they participate in was accepted. In practice, this is what is needed:
4. What are the requirements for identification of the users (e.g. required information, LoA, authentication method)?
Please select any of the following options that apply:
a) Globally unique persistent identifier,
(b) Name (First / Last name),
(c) Email,
(d) Affiliation with the home institute,
(e) Identity assurance (e.g. level of identity proofing, freshness of affiliation information),
(g) Other
1. Can you describe the research workflows?
(consider 2 aspects: producer side and consumer side)
(guidance only - currentlz a bit technical)
Would it help to provide options for the service types? E.g. Please select the most appropriate service types for services in your RI:
a. Browser Accessible Service: A service that provides a web interface that can be accessed by users using their browsers (e.g. A research data visualisation tool accessible through a web browser).
b. API Consumed by or on behalf of Users: A service that provides an API that can be consumed programmatically by the end users or by other services using user-delegated credentials. (e.g. A data analysis API allowing researchers to programmatically retrieve and analyse datasets).
c. API Consumed by Services: A service that provides an API meant to be consumed by other services. These services do not act on behalf of the user but have their own access rights to the API (e.g. A workflow management system might offer an API for other services to submit data jobs, monitor progress, and retrieve results.).
d. Client consuming Service APIs using delegated user identities: A client that uses access tokens authorised/delegated by end users and which can use these access tokens to access “APIs Consumed by or on behalf of Users” (e.g. A research collaboration platform might offer an API for data analysis tools. Researchers can authorise these tools to access their research data stored on the platform using delegated access tokens).
e. Client consuming other Service APIs using its own client identity: A client that uses its own identity and access token to access “APIs Consumed by Services” (e.g. A tool accessing a storage service API using its own client credentials to transfer data).
f. Public Access: A service that does not require users to be authenticated and authorised before they can access its resources (e.g. A public dataset repository where anyone can access datasets without needing to log in). - two sides to this question: on ingress of data into a data source, and on egress, which may be un-authenticated. Does your infra need to distinguish between these two cases?
Based on the workflow we could ask sub-quesions such as:
Do users of other infrastructures access services provided by your Research Infrastructure using your AAI? If yes, can you describe? (Please also mention your future plans in this area.)
(collect generic answers via E.1 question, then discuss in details with E.2 questions ad quideline)
As we collect the answers, we will try to identify common requirements. We can use the EOSC AAI requirements as basis for this:
What about Policy related questions, e.g.:
GDPR - MyAccessID at GEANT