Local registration enabled in production

[michzimny]

A user has a choice to go with federated authentication or a local account (and local registration). Shall we disable the local options? The federated one should be the only one for end users.

[vogias]

This is reasonable.However the sword plugin currently connects to dspace using simple auth method. So i need to check the complications if i disable this.Probably it wont be able to push to dspace from Moodle.I need to check this...

[andreacorleto]

In the pre-pilot phase (starting from april) probably we will not have users going with federated authentication. Currently, local registration is not working. How do users login to DSpace?

[vogias]

In order the simple login regitstration to work, dspace needs an SMTP server which will be responsible for sending all the related emails. The VM that hosts UP2U Dspace is located to GRNET's Okeanos Cloud where the related to SMTP ports are by default disabled. So we need an SMTP server set up to another cloud. Is there anyone willing to setup this?

[michzimny]

We don't want local registration in particular services. Users authenticate using SSO. In SSO they can choose to authenticate via either eduGAIN, or social media accounts, or local registration in the SSO.

DSpace should have its local registration disabled.

Please not that local registration in DSpace is something different than local registration in the SSO. The latter is ok and provides access to all Up2U services.

[andreacorleto]

Ok, I got it.

[michzimny]

Is our conclusion that we don't need local registration in DSpace? If so, could we hide the local registraion/login links?

[vogias]

i agree

[andreacorleto]

Me too

[vogias]

Done.

[michzimny]

Thanks!