iOS + Adfs + Shibboleth IDP

Wed Apr 8 21:51:00 EDT 2015

Scott

Your the best as usual. 

Here we go. 

iOS connects to Office 365
Redirects an embedded frame to ADFS
ADFS selects Shibboleth as an Identity Provider
Embedded frame redirects to shibboleth idp
Redirects back to adfs without asking for authentication

We see the following log entry in our IDP. 

20150409T011330Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|id-1a1341e9-af4f-4896-850f-280f9525afe1|http://adfs.fau.cc/adfs/services/trust|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://sso.fau.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_5b735d6ec12dbf6d14a9082b08f49c85||||||

Error message in ADFS is: The authority key for certdata 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfauthority' was invalid and will not be added to the authorityCache

*Which makes sense because Shibboleth seems to reject the request.

Here is a trace from the access log and idp-audit.log
10.19.48.201 - - [08/Apr/2015:21:49:27 -0400] "GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=jZLditswEIVfxejelm1iOxaOISQUArvdkpRe9E6RRkRgS65GbnbffmWlgZZlQ%2b%2fEaH7Od2Y65OMwse3sL%2bYIv2ZAnxz2G6Jl2pxhVVeFTFtRNunq3K7Tc9HUadOcq1KsVa2qmiQ%2fwKG2ZkPKLCfJAXGGg0HPjQ%2bhvKjSfJXm7fe8YKuWlVVWt%2bVPkuzDHG24j5UX7ydklCLaTPE5AzlTLSc6Oav0APS0fX4q6RGkdiA8PZ1eSLKzBmGZMTvDLEeNzPARkHnBlnwW5DBxS2KzwQmEVhokSb5YJyDyboh3M5DkdRwMsmjE435BkLfCDqTvIqi7lT4u4ojgFlDSL6CBk0uFEVSI%2bKYh4bcWgDToQd%2fRW%2fO%2bu%2b3ma2h52H%2bzgxZvi%2fqRP8AusiJGwv5UTP0XfjsM9rpzwD3c6el9zp%2f1g4zmBIM9vPr759%2bx3RCYjqD%2b37iPHqC4wMgxG7VwFq3ymbAjvSIt83xN8zocQNic9m%2bUh8nLU8RrGcFfrKRT6Hi1Tnb0c3n9%2ffMTMPrx9Pt3&RelayState=704a1051-b4f9-4dc7-a1ce-85e217f52652 HTTP/1.1" 302 -
10.19.48.201 - - [08/Apr/2015:21:49:27 -0400] "GET /idp/AuthnEngine HTTP/1.1" 302 -
20150409T014927Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|id-7be4651d-9c27-4b98-b176-77b52c8f6f56|http://adfs.fau.cc/adfs/services/trust|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://sso.fau.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_d5d8a5d71e6ff9fdbc9282b1f2a8cf07||||||
10.19.48.201 - - [08/Apr/2015:21:49:27 -0400] "GET /idp/profile/SAML2/Redirect/SSO HTTP/1.1" 200 1849

Rhian Resnick
Assistant Director Middleware and HPC
Office of Information Technology

Florida Atlantic University
777 Glades Road, CM22, Rm 218
Boca Raton, FL 33431
Phone 561.297.2647
Fax 561.297.0222

________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Wednesday, April 08, 2015 9:35 PM
To: Shib Users
Subject: Re: iOS + Adfs + Shibboleth IDP

On 4/9/15, 1:03 AM, "Rhian Resnick" <rresnick at fau.edu> wrote:

>Evening,Our ADFS and Shibboleth integration saga continues. Our users are
>reporting issues using iOS and Android Office 365 (word, excel, etc) when
>connecting to ADFS and we are receiving the
> following error in the ADFS log.

Can you describe where Shibboleth fits into any of that, and what role
ADFS is playing? I'm going to guess ADFS is somewhere in the middle and
it's forwarding to Shibboleth for authentication.

>
>Issue 1: “Unknown Auth method” message when you try to sign in to an
>Office app for iOS or Mac

Is that the error you're getting?

>This error can occur in a topology where an enterprise has federated an
>AD FS server with Azure Active Directory for signing in to Office 365,
>and further federated the AD FS server with another non-Microsoft
>federation server such as Shibboleth. When Mac and iOS Office
>applications sign in, Azure Active Directory sends a parameter in the
>sign-in request to AD FS that requests forms authentication. When AD FS
>relays this request to the non-Microsoft federation server, it may be
>unable to interpret this parameter and it may display an error to the
>user, even before they are asked to sign in.

I can only go by what that literally says, and it seems to say that they
are attaching an illegal parameter not defined in SAML, which of course
would be a bug (theirs).

Maybe you could trace it in the server access log on the IdP, if it's a
redirect anyway. We can probably identify the bug if there's an example to
look at.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net