Hello,
we have a farm setup. Each sub wiki is specific to a customer context. Customers would like to get SSO for their own context.
Is it possible to define the authentication method in the sub wiki? Is there a way to create a xwiki.cfg for the sub wiki or override the xwiki.cfg on sub wiki level?
Any pointers would be nice.
Thanks in advance
Jurjen
Currently what is configured in xwiki.cfg apply to the whole farm so there is only one authenticator.
That being said if you need a completely different authenticator system for each wiki it would not be too hard to create an authenticator which job is to call the right authenticator depending on the current wiki.
Note that some authenticators also allows setting the configuration at wiki level, for example the each wiki can have a different LDAP setup (but it’s still LDAP for everyone). So it all depends how different those wikis need to be.
Thank you, for your answer @tmortagne.
We suspected so much, based upon the xwiki.cfg.
Question then is, did somebody already created something like this?
Regards
Jurjen
I could not find anything in https://extensions.xwiki.org/xwiki/bin/view/Extension.
If you want to give it a try you could take a look at https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HCustomAuthentication.
Hi @tmortagne
We are thinking about the following and since you are the author of OpenID Connector…
What if we say for the farm authentication should go through OIDC.
We connect the OIDC to keycloak
Each wiki should then have a pointer to the specific keycloak configuration. Keycloak manages the authentication.
Regular LDAP authentication is then done on our separate LDAP
SSO for customer is then routed to the customer ADFS.
Is it possible to provide per sub wiki the information to pass through to key cloak?
We have successfully set up a situation with OIDC to one customer site, using a dedicated tomcat server.
However in the farm it would be better not to have separate tomcat servers.
Basically what we need is:
oidc.endpoint.authorization=/auth/realms/${actual xwiki name}/protocol/openid-connect/auth
where ${actual xwiki name} = the sub wiki name. Is the use of such a variable possible with OIDC?
Thank you in advance
All OIDC properties can be set at wiki level since they use the standard XWiki Configuration source: you can add the property you need to the XWiki.XWikiPreferences class and the value to the object. There is no dedicated wiki level OIDC configuration provided so you will have to use standard Class and Object editors.
But don’t really see what you can do with this setup that you could not do directly with LDAP. Looks like unneeded complexity to me.
Hi,
Could you elaborate on that? How do you envision each subwiki with its own single sign-on?
Regards
Jurjen
It really depends what you exactly means by single sign-on and what you can have or already have in your organization.
For example if all subwikis share the same main domain (wiki1.mydomain.com, wiki2.mydomain.com, etc.) then you don’t need to authenticate again when you move from one wiki to another. Just need to indicate mydomain.com in xwiki.cfg xwiki.authentication.cookiedomains.
If you are in a Microsoft environment you could use something like NTLM, Kerberos, etc. and configure the LDAP authenticator trust feature (xwiki.authentication.ldap.remoteUser* properties). In such a setup user never enter any credentials and XWiki just do what it’s told and the decision related to who is allowed to access which domain is in the system which actually take care of the authentication (for example https://github.com/Waffle/waffle).
The same trust feature can also be used with various other SSO systems as long as you find a module which takes care of the actual authentication at application server or proxy level.
Of course you could also use the OpenID Connect extension indeed. One current limitation is that the OpenID Connect authenticator currently does not automatically check if the client is already authenticated on the identity provider so when you come back after a while (i.e. when your session is lost) you have to click login (which go to the provider and come back right away but still annoying). No real technical blocker, just did not had time to work on that yet.