Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using SSO (Single Sign on) with SAML assertion with Custom profile attributes and badges

Not sure this will be of much use for many, but hopefully one day it saves someone hours of time and a big headache - This is how you both solve for passing custom profile attributes via SAML into Khoros, as well as how to make badging work with custom profile attributes. .

*Note - I am not an engineer, I have literally no idea what I am doing, but I made it work. If anyone has advice how to better do any of this, please share!

In my situation, we are utilizing OKTA as our IDP, which we want to pass custom profile attributes into Khoros. For example, we award badges in Community as people complete training in our LMS system. As such, when users complete the learning, their OKTA profile is updated to reflect that, and then OKTA passes that completion value into Khoros, which kicks off awarding the specific badge. 

If/when you want to utilize your SSO integration with Khoros to pass over custom profile attributes via the assertion, this is how you do it. How Khoros calls out custom attributes is very literally different each step of the way, so pay attention to each snippet.

Within your SAML Assertion Mapping settings page in the 'Dynamic Assertion Mapping' field -  - /t5/bizapps/page/tab/community%3Aadmin%3Afeatures%3Acommon.feature.samlss%3Asaml-sso-admin-mapping

You want to map it like this






1.PNGBadge Logic
If you want to then map custom profile attributes with badge logic you need to use the following (Notice it's different)



custom.custom_profile.comm_301 = 'Toast'



Does it work?
And then when you want to actually check if it all works, go into the API browser in stage and check with



SELECT c_comm_301 FROM users WHERE id = '47'




Which provides you with the results



  "status" : "success",
  "message" : "",
  "http_code" : 200,
  "data" : {
    "type" : "users",
    "list_item_type" : "user",
    "size" : 1,
    "items" : [ {
      "type" : "user",
      "c_comm_301" : "Toast"
    } ]
  "metadata" : { }



And that's how you do that! 🚀


For anyone curious, this is how our OKTA Assertion is setup while I was testing it



edit #5 - I give up on trying to format this thing to make it pretty, yall get the point!

12 Replies 12

@StanGromer We're actually not even getting that far. When we use Okta to log in for some reason the sso id in community gets set to the user's email address.

Any hints how to make Okta send the ldap uid to the community's sso id field? 🙂

@PerBonomi Here's how we're passing it over in OKTA, at least at quick glance I think it's the two spots that would matter:


Thanks @StanGromer !

We don't have all the same settings, but you helped me remain persistent and it seems to work now 🙂


Thanks @StanGromer for sharing!

I don't know how this could work with our SSO protocol, but we do have a cross-resource gamification on our roadmap. This may indeed turn out to saving hours of work in the future 🙂 We'll see 🙂 



Can Khoros integrate with more than one IDP provider for the same community?  For example we may use one provider for employees and internal users and different one for our customers

@chanda45  Yes it is possible to integrate with multiple SAML IDPs. There is a config and a setting that would have to be enabled. 
cc @NarendraG 

question on 'role mapping' -

We seem to only be able to 'push' one role when a user logs in.

I can see they need to be comma-separated.
If there are multiple roles being pushed by Okta - it looks like this might be the reason why it's only pushing the first in the list.

does this make sense to you? any idea how to 'intercept' / reformat the roles list before it gets into the assertion post at login?


@MorganBB standard community functionality of role assignment/removal requires the roles to be in separate comma-separated lists (one for roles to add, another for roles to remove) in order to be processed by the community. You could try adjusting your IDP settings to pass roles to add in a single comma separated list instead of each role being contained in separate SAML attributes. If you are unable to make that change on your side it would require a customization project to account for that on the community side.

Following my own guide, and it no longer seems to work 🤣  Stay tuned and I'll update as we figure out what we did wrong. (Different company so could be a lot of things)


Yes - we've had issues recently with assertion mapping between okta and Khoros... so thats why we've changed tactic and gone down the route of utilising Okta Workflows to assign the user to a role via API and assign the badge in khoros off that (we could use this to push/update the data in the khoros profile too) but utilising oktagroups=khoros role simplifies most badges.

This avoids relying on Khoros support to create the custom profile fields.
The process is repeatable and managed by Okta Group membership.

Which also makes it easy to trigger from external sources. 

Eg: Learning center webhook upon course completion.
Triggers flow which checks if there is a corresponding okta group and adds the user if there is.

Then the api adds the role, khoros adds the badge.

Just coming back on this to update - SSO/IDP couldnt change it - after raiging this as a support case with khoros its resovled.


Did you get any further with figureing this out?
Are we still limited by the need for Khoros to create custom profiles?

Welcome to the Technology board!

Curious about our platform? Looking to connect on social technology? You've come to the right place!

Are you a Khoros customer? For direct assistance from our Support team, please visit the Support Forum.