...
- The title is the use case
- Each line is a step
- 2 columns available, first with text and description, second with a screenshot
(Here's a valid example LINK)
Use Case 1 - Access to service
| Access to Rshiny (for the moment) | ||
|---|---|---|
| 1. | Access RShiny research service to analyze/calculate thermoclines in water columns.
|
|
| 2. | The User is redirected to LifeWatch IdP |
|
| 3. | You can select among the list of federated institutions belonging LifeWatch. For example, IFCA SSO will redirect you to the IFCA IdP |
|
| 4. | Overview of attributes being shared (to authenticate and perhaps authorize)...... |  |
| 5b. | The user is successfuly redirected to Rshiny app |
|
Use Case 2 - User Role Mapping (Researcher Vs. Citizen Scientist)
| Access to Rshiny (for the moment) | ||
|---|---|---|
| 1. | LifeWatch ERIC IdP needs to federate different institutions and different social ids to distinguish between different types of users (Researchers, citizen scientists...).
|
|
| 2. | Keycloak allows mapping to defined roles depending on the identity provider used for accessing. |
|
| 4. | It can be configures to propagate that information as an attribute for a service. |
|
| 5. | So the service can get that info and decide if the user has or not access rights. |
|
Further information
Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.