In case you are trying to implement single sign on with the MobiControl console, we are finally moving forward after a long running open case. Here are some items to be aware of when setting it up that are not currently documented:
Under the "IdP Settings" header it states: MobiControl implements the web browser SSO profile of SAML 2.0 specifications. Refer to the SAML 2.0 specification for more information on SSO profiles.
The SAML specification documents two SP initiated and one IdP initiated methods. MobiControl only supports one of the three (5.1.2 SP Initiated POST/Redirect). That is not documented and was an initial obstacle as our company default is to use 5.1.4.
The Identity Provider Manager utility page has a button to import the IdP metadata file. It is broken because it does not fully support the http://www.w3.org/2000/09/xmldsig#schema. It will fail if your metadata file X509Data section has anything besides X509Certificate. If it does not require the other X509Data items it should just silently ignore them rather than failing. At any rate, manually editing the metadata XML and removing the other X509Data items was required in order for the Import button to work correctly.
MobiControl REQUIRES that the assertion response from the IdP be signed. The spec only mandates that the assertion itself be signed, not the response. If MobiControl requires the response ALSO be signed then it should be documented somewhere.
MobiControl CANNOT accept an encrypted assertion. It SHOULD be able to accept one but it cannot. That detail is also not documented anywhere.
MobiControl implements a user authorization mechanism that is based on an additional AttributeStatement section that contains one or more group names associated with the authorized principal. Those groups determine what access the user is allowed. The "Group Settings" section of the help document states:
Enter a List Attribute and, optionally, a List Delimiter. A List Attribute is an assertion attribute in the incoming SAML authentication response that contains groups. A List Delimiter splits up attribute values into multiple values. If a delimiter is not set, it is assumed that the attribute value contains multiple XML nodes, each one a different group name. No where in the documentation does it state that THESE GROUP DEFINITIONS ARE WHAT IS ACTUALLY USED TO AUTHORIZE THE USER. So, you need to create "IdP User Groups" in the Manage Users section of the console and provide the desired access to those groups. You also need to create those attribute values in your IdP and assign those values to users in the IdP. Then, provide the values in a AttributeStatement section of the assertion response. These attribute values are matched against the defined "IdP User Groups" to determine the access the user is afforded.
Hopefully you can avoid some of the headaches I encountered going down this path.
