We’re looking for a way to get our remote users authenticating with the office systems whilst they are on the road, or in these troubled times working from home.
Not wanting to expose our LDAP to the internet it would be worth looking at using the existing Open Source OAuth2 solution we have – Keycloak.
Continue readingAfter getting Keycloak up and running, it’s a breeze to connect it to LDAP and use the users from there, but there were a few things I missed about group membership and there’s a fun quirk to fix about the user name.
First task after creating a new realm is to go to User Federation and add an LDAP provider. Fill in all you details for the LDAP server – I’d advise you to use an account that has writeable access to your people OU at least. This is so you can leave Keycloak to manage your users and let them have a self-service portal for changing their passwords.
Continue readingSingle Sign On from a simple docker container set.
The container might be simple but the complexities of OAuth2, SAML and identity services are far from straight forward. For some time we’ve been using applications that can provide OAuth2 services as authenticators. This needed to change as we were looking to broaden the capabilities of our authentication processes to encompass 3rd parties and various authentication realms – from trusted, untrusted and community sources.
Continue readingWith a move to a more joined up authentication using Single Sign On (SSO) I deployed a Keycloak service in a docker container – that should probably form part of a later article.
Keycloak provides the bridge between OAuth2/SAML and LDAP authentication. Rather than relying on the same passwords and having to type the same credentials time and again, into various corporate applications, we can now setup the application with a client in keycloak and use tokens across authentication our landscape.
As we use MediaWiki for the bulk of our corporate knowledge it made sense to add in Single Sign On.
Continue reading
Stuff I'm Up To 