SSO Via Okta - User being logged in with different BBID

Options

I have a user who has an email alias. The BBID was created using the email alias. When we set up SSO we didnt know that he had an alias, so When SSO was enabled, it created a new BBID for his primary email. Ive since modified his username in Okta to be his alias address, but When he authenticates into Blackbaud, it is still logging in with the primary email which has no access, and even states that it isnt a part of our organization. The BBID with the primary email is not listed in the admin console so i cant manage/delete it and BB Support essentially told me there was nothing that could be done.

Here is a quick list of accounts for clarity:

Blackbaud Accounts -

BBID1 (Alias Email) - Original BBID with correct access. Has been used for years

BBID2 (Primary Email) - Newly created BBID when SSO was implemented. No access and not manageable in Admin console

Email Accounts:

Email1 (Alias) - Matches with BBID1 - Configured in Okta as the username for this user

Email2 (Primary) - Matches with BBID2 - Not configured as Username, yet still appears as the name of the BBID2 email.

Has anyone experienced anything like this or has a suggestions?

Comments

  • @Drew Aydelott Hi! I was reviewing your case with Blackbaud support. I see the last thing instructed was to reach out to Okta to see if you could remove that email. Would you be able to chat back in to let them know that you reached out to Okta and are still having issues?

  • @Crystal Bruce
    Hi Crystal,

    I reached out to Okta support but have yet to hear back. I have confirmed that the users Okta profile has the correct alias email address configured, even though the login to Okta itself is the primary email address. In regards to the BB support suggestion, there is not a second user account in Okta, nor is there one in Blackbaud from what i can see via the admin console in both services. It honestly seems like there is a second account that exists in BB that the SSO connection is logging in with, however i cannot manage it because it is not associated with my organization.

  • I was able to determine the issue with the assistance of Okta support. The issue lies a little bit on both sides of the fence (BB and Okta) due to attribute mapping, and neither application respecting the username field in Okta.

    Even though Okta has a Username field that modifies the username for the assigned app, The SSO integration using SAML uses attribute mapping to directly transfer the attributes, ignoring the Username field. (In the SSO setup documentation its section "1>5>c" that refers to

    For email, enter ${user.email}.

    For given_name, enter ${user.firstName}.

    For family_name, enter ${user.lastName}.

    The email mapping was what needed to be modified. In Okta, a new custom attribute string was created for the Financial Edge App that mapped email to email. After that, the attribute was mapped in the application under General>Sign On>Attribute Mappings. ${user.email} was replaced with appuser.email?:user.email

    Once that was completed, it was just a matter of filling the correct email address on that user's app settings, and they were able to log in.

Categories