2020 InCommon Virtual COmanage Class: Nov 10-13, 2020

[Scott Koranda <>]

Hi,

There were three (3) outstanding questions from the InCommon COmanage
Registry training last week:

1) Problem getting the LDAP Provisioner to provision all
members of the CO:members:active group.

2) One approach to bulk invitation flows.

3) Creating the necessary Docker Swarm secrets used for the
training deployments.

Below are answers, inputs, and comments on each of those.

Thank you again for attending the training and your interest
in COmanage Registry.

Cheers,

Scott

------------------------------------------------------------------------

1) Problem getting the LDAP Provisioner to provision all
members of the CO:members:active group. 

This did turn out to be a bug in version 3.3.0 and 3.3.1 of
COmanage Registry in the background asynchronous LDAP
Provisioner jobs. It can affect other groups as well, but it
does not affect synchronous provisioning (for example, if you
just make an edit to a single CO Person record).

The good news is that the bug has been identified and a patch
(one line it turns out) created and this should be fixed in
version 3.3.2, due out soon after Thanksgiving.

2) One approach to bulk invitation flows.

You can tie together a couple pieces of functionality to
create a type of "bulk" invitation flow functionality. This
was done for a particular deployment but the functionality is
now in COmanage Registry 3.3.0.

The first piece is to create an Organizational Identity Source
(OIS) using the API Source plugin:

https://spaces.at.internet2.edu/display/COmanage/API+Source

This OIS plugin supports "push" over HTTP.

It also supports an (optional) returnURL:

"returnUrl is optional, and consists of a single string
containing a URL. This URL is used as a Petition-Specific
Redirect Target, if API Source is connected to a Pipeline that
in turn is connected to an Enrollment Flow. Make sure the
returnUrl is configured in the Enrollment Flow's Return URL
Whitelist configuration."

Next create an invitation enrollment flow, similar to how we
did it in training. You don't need any Enrollment Attributes
since no form will be shown. Instead the invitation flow will
be triggered by a pipeline attached to the API Source OIS. 

Details on what is needed for the invitation flow are at

https://spaces.at.internet2.edu/display/COmanage/Registry+Pipelines#RegistryPipelines-TriggeringPipelinesFromEnrollmentFlows

The next piece is to create a pipeline as we covered in
training. The pipeline should be attached to the API Source
OIS and configured to trigger the invitation enrollment flow.

So with this configuration you can push information about the
enrollee in via HTTP, it will be consumed by the API Source
and an Organizational Identity will be created. Then the
pipeline will create a skeleton CO Person record and then
trigger the invitation flow to run, sending the user the email
with the email verification nonce/link it in. Once the user
clicks on that link the flow will run to completion and the
enrollee will be onboarded.

3) Creating the necessary Docker Swarm secrets used for the
training deployments.

Below are the details for how you can create the same secrets
that were pre-populated in the training environment when you
arrived.

comanage_registry_email_account_password

This secret is the password needed for authenticating the SMTP account so
that COmanage Registry can send out email. The SMTP account is
set as an environment variable (see the Docker Compose file 
comanage-registry-stack.yml) but the password was stored as a
secret and pointed to by an environment variable.

If the password is 'smtp_secret' then you would do

echo -n 'smtp_secret' | docker secret create 
comanage_registry_email_account_password -

olc_root_dn_password

This secret is the (bare) password needed by the OpenLDAP
slapd container so that when it starts up it can process the
bootstrap LDIF file that defines the directory structure. If
the secret is 'admin_password' then you would do

echo -n 'admin_password | docker secret create olc_root_dn_password -

olc_root_pw

This secret is the hashed password for the admin user for
the slapd. It is the hashed version of the password stored in
olc_root_dn_password. This secret is used to bootstrap the
directory itself (before the LDIF bootstrap file is
processed).

To obtain this secret, run

/usr/sbin/slappasswd -c '$6$rounds=5000$%.86s'

and when prompted enter the password.

The output might look something like this:

{CRYPT}$6$rounds=5000$CvFwftdm1nwv2I7N$C3eMEVBGa/2PYlxGnF0DBPNzlDkR550C4Ol5ooerk47XOI73Z9VDzt1ZHbQ1MmmCwzCSd1h.NvUqmmxzCNRaC.

You can then take that output and do

echo -n 
'{CRYPT}$6$rounds=5000$CvFwftdm1nwv2I7N$C3eMEVBGa/2PYlxGnF0DBPNzlDkR550C4Ol5ooerk47XOI73Z9VDzt1ZHbQ1MmmCwzCSd1h.NvUqmmxzCNRaC.'
 | docker secret create old_root_pw -

The last four (4) secrets are SAML certificate/key pairs used
by the Shibboleth SP. You need one cert/key pair for
encryption and one for signature. You can use the same
cert/key pair for both, but it is less secure.

Assuming you have these four (4) files in PEM format

sp_encryption.crt
sp_encryption.key
sp_signature.crt
sp_signature.key

you would then run

docker secret create shibboleth_sp_encrypt_cert sp_encryption.crt
docker secret create shibboleth_sp_encrypt_privkey sp_encryption.key
docker secret create shibboleth_sp_signing_cert sp_signature.crt
docker secret create shibboleth_sp_signing_privkey sp_signature.key

The last two secrets used during training are

mysql_registry_user_password

and

mysl_root_password

Both of those were secrets you learned how to create in the
course documentation in Canvas.

Thanks,

Scott