Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Update current configuration system to use an array of sources #26

Open
madmatt opened this issue Jul 18, 2018 · 0 comments
Open

Comments

@madmatt
Copy link
Member

madmatt commented Jul 18, 2018

Currently, the SS_ENVIRONMENT_TYPE that you are on (dev, test, or live) influences which RealMe environment is connected with (mts, ite or prod, respectively).

This systems works at a glance, but makes it difficult to test against different RealMe environments from the same environment (e.g. testing against RealMe prod on the test website, in order to debug an issue with the live website's RealMe integration). Provided the certificates are in place, it should be more straightforward to change this with code.

Additionally, it would be ideal to have multiple different integrations supported by the one module. For example, enable the use of both login and assert with the same installation - at the moment the module supports only one or the other.

Finally, there are some use cases where multiple authentication sources make sense. For example, consider a website where you are invited to use the system and login via RealMe. If you are sent an invite, then you would want to pass through AllowCreate=true to RealMe, in order to tell RealMe that you allow people to create new RealMe accounts before returning the user back to the website. However, it doesn't make sense to pass AllowCreate=true when users are just logging into the website later (e.g. when they are not accepting an invite), because they won't be able to login with a fresh RealMe account unless they were following an invitation link. So when rendering the normal login form, you would use an auth_source that has AllowCreate=false, and when rendering the login form during the invite process, you use an auth_source that has AllowCreate=true set.

I see this working primarily by changing how the YML configuration is specified. Instead of specifying different values for mts, ite and prod, you would instead specify an entire auth_source block for each of mts, ite and prod. A quick mockup of this could be:

SilverStripe\RealMe\RealMeService:
  auth_sources:
    mts_login:
      realme_env: mts
      integration_type: login
      sp_entity_id: https://dev.your-website.govt.nz/p-realm/s-name
      authn_context: urn:nzl:govt:ict:stds:authn:deployment:GLS:SAML:2.0:ModStrength
      metadata_assertion_service_domain: https://dev.your-website.govt.nz
      # etc
    mts_assert:
      realme_env: mts
      integration_type: assert
      sp_entity_id: https://dev.your-website.govt.nz/p-realm/s-name-assert
      # etc

Once multiple authentication sources are required, the RealMeAuthenticator, login form etc. would all need to support some way of selecting the correct authentication source. This would then be controlled by the developer - for example simple websites might just configure it via YML, based on SS_ENVIRONMENT_TYPE like the current system does, where dev => mts, test => ite, prod => prod, but more complex flows could be built as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants