We used OKTA so the step are in relation to that.

SOTI Mobicontrol Single sign on can be setup via LDAP or IdP connections. 

We used IdP connections to setup applications with OKTA.

Note: Mobicontrol is an SP initiated application which requires access from the web link and not initiated from OKTA.

Setting up IdP connections:

IdP connections can be used for SOTI MobiControl console authentication and (if backed by LDAP) to enroll devices.

To add an IdP connection to SOTI MobiControl:

1. On the All Platforms tab, select the Servers tab.
2. Under Global Settings, click the wrench icon beside Identity Provider Configuration to open the Identity Provider Configuration dialog box.
3. Click the New button and fill in the fields with the appropriate values.
4. Click Download the SOTI MobiControl metadata file to your desktop to save our metadata file to your computer.
5. Click OK to save your settings and close the Identity Provider Configuration dialog box.
6. Follow your IdP's instructions on adding a new client to complete the connection.

Note: IdP connections in SOTI requires “List Attribute” to be setup this is used for the “Groups” to be passed through in SAML assertion.

Enable SSO:

1. On the All Platforms tab, select the Servers tab.
2. Under Global Settings, click the wrench icon beside Console Security Settings to open the Console Security dialog box.
3. Switch to the SAML SSO tab and check the Enable SSO box.
4. Select an IdP group from the drop-down list and click OK to save your settings and close the dialog window.

Your IdP connection is now configured for SOTI MobiControl console access and (if backed by LDAP) device enrollment.

OKTA Applications Notes:

SOTI is case sensitive and requires that all data be exact when setting up the application in OKTA.

Meta data can be loaded into SOTI but not into OKTA. SOTI Metadata does contain the Single Sing on URL however the audience URL is difference and needs to be reviewed to the case sensitive nature of the SAML validation.

Hello Joe,

Thank you for your post, are you using OKTA to set-up web-console sso?

Regards,

Correct trying to do the SSO to the web-console

Hello Joe,

Please provide screenshot of IDP configuration from MobiControl web-console

Thanks,

List Attribute was questionable

Hello Joe,

Thank you for your response,

Did you add this group in User and Console Security section?

Regards,

I did yes

Even made a new group to go with it 

Hello Joe,

Thank you for response, I believe we need to further investigate what exactly happening on your end

As I cannot ask you to share screenshot of OKTA settings, I request you to create Support ticket. Our support team will be happy to help you.

Regards,

Could be several things going on but for one thing, SAML string values are assumed to be case sensitive so your group name definitions should match exactly.  Your screenshot is showing all uppercase group definition but the name in the list box is not.

Having said that, those entities are not the same.  The List Attribute is not itself a group definition.  It is an attribute that will be returned by the IdP and it will contain one or more group names, separated by the character specified in List Delimiter.  Those values are what need to have matching MobiControl IdP group definitions.

To better understand what is happening, enable verbose logging on the management service and then look at the ManagementService.log file.  It will contain the entire IdP transaction data.

I was able to make some progress with the configuration but I think the issue is really down to the list attributes and what should or shouldn't be assigned to the IdP and user groups.

Currently I am failing with the error Invalid SAML 2.0 message. Assertion validation failed.

Since the SSO connection is only done on the SP side and the IdP required that I fill in the list attribute I wasn't entirely sure as what should have been passed. 

Reviewing some of the details that Scott has posted on https://discussions.soti.net/thread/sso-single-sign-on-fyi/ and knowing that it doesn't pass an encrypted assertion we cant simply load the certificates.

The setup process has been a bit lack luster on what we need to pass. 

Hello Joe,

Following up on this thread, were you able to resolve the issue? If yes, I would like to know what were the steps taken to resolve the issue and I can mark that as a Solution.

OR

if the above posts has helped you in solving your inquiry, I would request you to mark the particular comment as "is solution", so others may benefit from this information.

Regards,

yes I was able to get this completed. I should have the process documented some place and can dig it up if needed

Hello Joe,

Thank you for your response, if possible try to share the steps, so others may benefit from this information.

Regards,