IdP-Initiated with Office 365

[Nate Klingenstein]

Kevin,

Most likely, you haven't provisioned an account that matches that
objectGUID + IDPEmail.  Alternatively, IdP-initiated SSO may not work with
Office 365.  Again, I have no way of testing myself, and I apologize.

Either way, your IdP apparently sent a full assertion to Office 365(you can
check your IdP's logs on DEBUG to see if the assertion looks right).  The
error is at Office 365 and pretty self-explanatory, so your best bet is to
double check the assertion for the right data and make sure your
provisioning is working and then visit the exciting land of Premier Support.

Take care,
Nate.

On Mon, Sep 10, 2018 at 11:39 AM, Kevin B <kevin at thenext.net> wrote:

> Thanks Nate,
>
> It appears it tries to sign me into Office 365 but then I get this message
>
> Sign in
>
> Sorry, but we’re having trouble signing you in.
> AADSTS51004: To sign into this application the account
> AAdzZWNyZXQx7HMxE6qicIZSOj9QzKVS.....+rUOUj91x5MsYdMZ0tib50s6FCFGB must
> be added to the 8f42c016-.....-772a011c3b99 directory.
>
> On Fri, Sep 7, 2018 at 11:39 PM Nate Klingenstein <ndk at sudonym.me> wrote:
>
>> Excuse me, 3A, not 3B.
>>
>> On Sat, Sep 8, 2018 at 2:51 AM, Nate Klingenstein <ndk at sudonym.me> wrote:
>>
>>> Kevin,
>>>
>>> I suspect that something like the below would work, but I don't have an
>>> account nor an IdP I can use to test it with.
>>>
>>> https://idp.host.here/idp/profile/SAML2/Unsolicited/SSO?
>>> providerId=urn%3Bfederation%3BMicrosoftOnline&target=
>>> https%3A%2F%2Fportal.office.com%2F
>>>
>>> Federated identity in general means fewer logins(but as many or more
>>> sessions total) but the number of logins does not depend on whether the IdP
>>> or SP initiates the process.  The number of logins depends on the IdP's
>>> session management and whether a current session exists for the user that
>>> satisfies a request issued by the SP.
>>>
>>> Unsolicited SSO may obviate the need to do IdP discovery, which would be
>>> the only reduction in required user interaction.  That's a win, but
>>> unsolicited SSO comes with other trade-offs.  You may need to end up
>>> supporting IdP discovery and SP-initiated SSO for Microsoft's native
>>> applications anyway.  It's worth reading through this Wiki article.
>>>
>>> https://wiki.shibboleth.net/confluence/display/IDP30/
>>> UnsolicitedSSOConfiguration
>>>
>>> The only data transmitted in the assertion is the user's objectGUID and
>>> a mysterious identifier known as IDPEmail, and the SAML assertion itself
>>> would be considered the credential from the SP's point of view.  Most of
>>> the heavy provisioning lifting is done by the descendant of DirSync.
>>>
>>> Hope this helps,
>>> Nate.
>>>
>>> On Fri, Sep 7, 2018 at 10:40 PM, Kevin <kevin at thenext.net> wrote:
>>>
>>>> How would one use IdP-Initiated SSO with Shibboleth and Office 365?  In
>>>> a
>>>> university settings would this not be fewer logins?  Would their be a
>>>> URL
>>>> nomenclature that one would use to pass the credentials to the SP?
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://shibboleth.1660669.n2.nabble.com/Shibboleth-Users-
>>>> f1660767.html
>>>> --
>>>> For Consortium Member technical support, see
>>>> https://wiki.shibboleth.net/confluence/x/coFAAg
>>>> To unsubscribe from this list send an email to
>>>> users-unsubscribe at shibboleth.net
>>>>
>>>
>>>
>> --
>> For Consortium Member technical support, see https://wiki.shibboleth.net/
>> confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180910/a3fe3691/attachment.html>