We ran into a problem with the Wordpress part of our demo ... we've started our attempts to fix it right away ... so the Wordpress-part might not be working. Or it's already fixed and Raoul Teeuwen forgot to take down this warning. If you find the latter is the case, he would appreciate an email at email@example.com and letting him know he can de-activate this warning .
We've created a demo-flow. Any questions about this demo you can email to firstname.lastname@example.org . It's our intention this demo 'always works', but we don't test it every week or so. If it somehow broke, please let us know! Our GÉANT colleagues are developing eduTEAMS, which, not entirely accidental, looks a lot like our SCZ. They also have a demo-environment, which you can use if ours doesn't work, or if you want to check out COmanage alternatives Hexa and/or Perun (GÉANT has a comparison of those three), or try other services.
Apart from the below demo where we use COmanage as Membership Management Service (MMS), we also have a demo with our own build SBS (Dutch Samenwerkings Beheer Systeem) MMS which can be found here.
As your institution probably hasn't connected their IdP to SCZ-FIAM, you can't use your institutional account to login. For the demo, you can currently login with a Google- or Microsoft-account.
Also: please, always check whether you have followed this demo instructions before telling us something doesn't work.
|If you want to show this demo to someone else while already having been signed-up, you can use a private browser window and sign-up again. |
If you use this option, don't forget to execute EVERY step in a private window, also opening the confirmation email link.
|Already signed up, but want to access the demo service? Access the demo Wordpress-site at https://wordpress.demo.scz.lab.surf.nl/ or COmanage via https://comanage.pilot.scz.lab.surf.nl/registry/ .|
COmanage, part of the current SCZ FIAM, lets administrators define several types of invitation flows, which are workflows to onboard researchers. You can find more about those flows in the documentation. You can for instance configure whether and what approval you want from for instance an admin.
For this demo, imagine the following: you have a service intended for researchers or you are a research collaboration. Researchers in the collaboration need access to several services, one of which is a website, in this case a WordPress-site (but the idea works for all/most services). The services have been connected to the SCZ FIAM platform. Normally you would not allow anybody access to your research services without knowing who they are. But for this demo you have decided researchers are allowed to self sign up for access to edit content on the Wordpress site, without any approval.
So for the demo we've configured a self signup invitation flow. It's basically a URL you can attach to a text or a button on a website of a research collaboration, with a text like
Now imagine you're a researcher that wants access.
Assuming you've read the above, there are 3 steps in this demo. A generic part (which creates a user in the demo COmanage Collaborative Organisation), after which you can both access a Wordpress site via your browser as well as a VM via SSH. Apart from showing you this works for both web and non-web, this also shows you that by creating just one user at the SCZ, access is created in several connect services.
This demo currently is showing you how one flow (of many configurable flows) works and one (of many) way of how a researcher could access a service based on the credentials and attributes in COmanage. Over time, we plan to extend the demo to show more aspects.
For people wanting to know how this works: when you click the button on the Wordpress site to sign in with SCZ, you get redirected to SCZ, which redirects you to your IdP (for instance Google) to authenticate. After authentication, you get redirected back to SCZ. Depending on whether you successfully authenticated, SCZ will gather some attributes and include those in the redirect back to Wordpress, upon which the authentication module of Wordpress is able to decide whether you get access and with what authorisation. All messages necessary for this process are digitally signed, so Wordpress knows the attributes are indeed received from the SCZ.
In the terminal window, we are going to access the machine at sandbox1.aws.scz.lab.surf.nl . So the command is:
ssh <your userid>@sandbox1.aws.scz.lab.surf.nl -p 2022
ssh email@example.com -p 2022