Hi @Jacob91 ,

What is the external IDP you are using to achieve SSO? That text that you see as the directory id is a temp value that KeyCloak uses when it is not able to match the inbound claim to a directory id against a user. Based on the IDP, we might be able to figure out why this is happening.

Cheers,

Hi Sajith,

We use Azure AD as IDP. It seems like you say we miss some information regarding the user in the token. Do we use ID token or Access token?
So far we have only configured Azure AD SSO as we would with IFS10 but with the difference being the URL. See picture below.

We also tried a few more claims other than default values, see below:

Lastly is there something we need to do with Attribute Mappers? We cannot find any documentation regarding it and if we try configure something here we get http error 500.

Hi @Jacob91 ,

For Azure AD it should be straightforward. You should not need to tick the access and ID tokens but having them ticked shouldn’t be an issue as far as i’m aware. 

Can you provide an image of you IAM external idp setup as well to see whether i can see anything unusual?

Cheers

Hi @Sajith D , im a colleague of Jacob.

Here is a screenshot of our IDP setup in IFS.
 

Hi @nioh,

For Azure AD, you would need the Userinfo endpoint lookup so uncheck the “Diable User info” which is currently checked. 

let me know how it goes after that change.

Cheers

Hi! @Sajith D , we have tried that already, with and without “Pass Login Hint” and “Pass UI Local” but nothing has so far made any difference.

Is the Userinfo enpoint a requirement for Azure AD? 

Hi,

I had the same issue as you for Azure AD. following How to set up External IDP - AzureAD | IFS Community has helped a bit. 

The directory ID comes in as a barbled mess but now I can get an email address to come through as the directory ID which is what we need.
We’ve been able to achieve this with the following setup:

IFS - IAM Identity Provider:

IFS - IdP Attribute Mappers
 

Azure AD - Token configuration

Azure AD - API permissions

(I think we granted more than we actually need)

Cheers,

James

Thanks James!

That worked. Did some more testing and for the API permission you only need the “User.Read”.
For the Token Configuration you don’t need the email ID/Token claim in Azure AD. And last, the scope can be only “openid” in IFS IDP configuration. Seems the attribute claim in IFS “email>email” and “User.Read” is all it needs to get the Email value from Azure and connect it to the ID Identity in IFS. 

/Jacob

does anyone know how to set this up for using UPN instead of email? IFS tech support doesn’t

Hi @Kendall ,

i don’t have a working example for this but including the “upn” as a claim in the token in the Azure AD setup (if not included already) and adding an attribute mapper with both the mapper name and the claim as “upn” should do the trick.

Cheers

Sorry I should have expanded on this a bit more.

I have tried all the usual things -- using upn for both fields, exposing upn in azure as an optional claim. 

using preferred_username in Azure - trying email in all sorts of configurations. The problem i was getting was when i set the directory id to our upn it was giving me a weird directory id as shown in the original post in this thread. now i am getting it to show my email address which is not even in ifs. so i am unclear on which way the mapping goes and to what fields. Thanks

I was struggling for a while on AzureAD Authentication and this setting seems to work !

Thank you !