Keycloak administration on AA Device Services with SAML 2.0 / Azure

[wallot]

Hi folks

We are having a very hard time finding anyone capable of administering keycloak. Avaya states they do not support keycloak even though Avaya includes it in the AADS and in the AADS documentation.

RedHat does not support it unless you deploy their version - RedHat SSO. And of course we cannot modify AADS in any case if we want to maintain Avaya support.

Bottom line is, we need a US citizen that can be vetted, that knows how to implement keycloak to SAML 2.0 and Azure.

Thanks!!

 

[kyle555]

It's not terribly hard, but they do skip a step here'n'there. How far along are you?

 

[wallot]

We've not even started the keycloak configuration. Until recently, I couldn't even spell keycloak

 

[kyle555]

on the initial install in the blue terminal, you can import a xml from O365 from the 'app' you build. And in the O365 app you put in a couple of URLs from Keycloak.

It's basically instructions on how to play weblink pingpong.

Your client learns from AADS that it should use keycloak - like aads.com/keycloak
Then keycloak says "go to o365.com/aadslogin" and your o365 app has that as a signin URL. and it also says "i was referred by aads.com/keycloak"
Now you authenticate, and the callback URL in o365 for this app will only ever be 1 URL like 'aads.com/keycloak/success'

Anyway, the doc is straightforward enough to do it through the menu - ultimately you're just supposed to create the app on 365 with the URLs defined in keycloak, get the XML, and put that in your "saml provider" in AADS.

There's also a part where you have to copy a key from the keycloak client tab to the AADS admin page.

The aads admin page has a test utility that you can run too to see how far you get and what's wrong with your token.

The trouble I had was having the claims pass from O365 to Keycloak. Those "claims" are things like email address - that worked. But, group didn't. So, if you have a East and West system and people logging in from the west coast get sent to the west SBC based on AD group, that would be a difficulty I have setting it up right now. But, you can also force claims on things, so they inherently pickup the first generic AADS user group you make, so that's how I got mine going now until I need to have to figure out how to pass that appropriate group membership in O365 to align with groups in AD to align to different dynamic config for users.

 

[dclark1111]

wallot and kyle555,
I am currently exploring keycloak as well. I didn't know if you have seen issues when doing a Client ID Mapping. For client ID I am entering aafd, then the url -

https://server.domain.com/auth/realms/SolutionRealm/.well-known/openid-configuration

and they the secret copied from the clients table in the keycloak admin page for aads (I am not removing the dashes).

I get an error dialog box that states:
Failed to add new client mapping.
Failed to discover OAuth information

We are using an internally signed cert for the OAM and the Application (under Server Interfaces - Identity Certs). Created cert by doing a Cert signing, having our server sign it and then assigning it.

Have either of you ran into this yet? Any idea where the log files would be?