Office 365 -> ADFS ->Shibboleth iOS problems?
Patrick Le
ple at jhmi.edu
Thu Aug 18 19:37:40 EDT 2016
I sent this earlier but the digest never updated. I guess I'm supposed to leave the message body intact on the reply (or maybe there's a response threshold that needs to be reached before one gets sent out). Anyways, new update: a fix should hopefully be in sight according to our support engineer:
" I'd like to let you know that the issue has been identified and operations is working on a fix for the apps which will then be published through Apple. The clients will need to be updated. I'll update you once I have further information."
-----Original Message-----
From: Patrick Le
Sent: Thursday, August 18, 2016 6:27 PM
To: 'users at shibboleth.net' <users at shibboleth.net>
Subject: Re: Office 365 -> ADFS ->Shibboleth iOS problems?
Received some promising updates from Microsoft support today. From our technical account manager:
"So we do have a mounting # of cases. They are working it on the backend as critical. I will check it again in the AM for you."
Hopefully they'll help us with a fix soon. Not sure if anyone opened up any tickets as a result of this thread, but if you did, thanks! I'm not sure about you guys, but I'm growing tired of authentication breaking every 3-6 months because Microsoft pushes out an update without testing the ADFS to Shib flow. The run around we consistently get is we are 1 of only 2 or 3 institutions that have our authentication setup that way. So it's nice to know that this setup is used more extensively than Microsoft thinks.
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of users-request at shibboleth.net
Sent: Thursday, August 18, 2016 4:39 PM
To: users at shibboleth.net
Subject: users Digest, Vol 62, Issue 101
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at shibboleth.net
You can reach the person managing the list at
users-owner at shibboleth.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..."
Today's Topics:
1. Re: OpenSAML 2.6.5? (Scott Shipp)
2. "Don't Remember Login" on example login page (Chris Reeves)
3. RE: "Don't Remember Login" on example login page (Cantor, Scott)
4. assertion signing defaults for IdP v3 vs v2 (Mark K. Miller)
5. RE: assertion signing defaults for IdP v3 vs v2 (Cantor, Scott)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Aug 2016 18:16:34 +0000
From: Scott Shipp <sshipp at expedia.com>
To: Shib Users <users at shibboleth.net>
Subject: Re: OpenSAML 2.6.5?
Message-ID: <F5ACC25A-7562-434B-A4F1-88943B82402B at expedia.com>
Content-Type: text/plain; charset="utf-8"
Thank you?turned out to be typical Maven bull, had to blow away the cache and poke it with a stick in the eye a few times.
On 8/18/16, 11:08 AM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
> Right?that?s why I pasted my pom.xml?is there something wrong with it
> then? Repasting below. It pulls 2.6.4 but not 2.6.5 or 2.6.6.
I didn't look at your POM, but they're definitely there.
https://build.shibboleth.net/nexus/content/repositories/releases/org/opensaml/xmltooling/
https://build.shibboleth.net/nexus/content/repositories/releases/org/opensaml/openws/
https://build.shibboleth.net/nexus/content/repositories/releases/org/opensaml/opensaml/
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
Message: 2
Date: Thu, 18 Aug 2016 19:18:36 +0100
From: Chris Reeves <chris.reeves at york.ac.uk>
To: users at shibboleth.net
Subject: "Don't Remember Login" on example login page
Message-ID: <20160818181835.GZ12358 at esgreeves.york.ac.uk>
Content-Type: text/plain; charset=us-ascii
Hi,
I've been trying to confirm what the "Don't Remember Login" checkbox which appears on the default login page is intended to do. The most useful reference I've found so far was a thread from last month:
Subject: Different SSO session timeouts based on IP
On Tue 19 Jul 2016 at 00:05:14 +0100, Peter Schober wrote:
> * Aaron Howell [2016-07-18 22:28]:
> > We have some "kiosk" machines that are always logged in. People are
> > using Shibboleth protected sites on them and forgetting to close the
> > browser or logout.
>
> Simply pre-selecting the "Don't Remember Login" (i.e., disable SSO)
> check-box on the IDP's login page in JavaScript based on client IP
> range would help a but, I guess.
Based on this thread I understand that the checkbox disables SSO between SPs, and my testing confirms this. The only reference that I've found to this checkbox in the documentation is here:
https://wiki.shibboleth.net/confluence/display/IDP30/PasswordAuthnConfiguration#PasswordAuthnConfiguration-ExampleVelocityUserInterface
although that doesn't actually describe what it does. I've perhaps missed something, but is this described anywhere else in the documentation? If not then I'm happy to update that page with a little more detail.
Regards,
Chris
------------------------------
Message: 3
Date: Thu, 18 Aug 2016 18:26:54 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: RE: "Don't Remember Login" on example login page
Message-ID:
<9846A6064BD102419D06814DD0D78DE1129F5859 at CIO-TNC-D2MBX02.osuad.osu.edu>
Content-Type: text/plain; charset="us-ascii"
> I've been trying to confirm what the "Don't Remember Login" checkbox
> which appears on the default login page is intended to do.
To be precise, it triggers a per-request flag that suppresses the storage of the AuthenticationResult into the IdPSession object. As a result, the next request doesn't see an "active" AuthenticatonResult from that flow, causing it to run again, ergo no SSO.
> Based on this thread I understand that the checkbox disables SSO
> between SPs, and my testing confirms this.
It's preventing SSO by preventing the storage of the outcome that would make SSO possible.
Login flows can manipulate a setting at runtime to tell the system what to do, meaning the checkbox is an example of something that triggers a more generally available feature buried inside the depths of the authentication interface in the system.
-- Scott
------------------------------
Message: 4
Date: Thu, 18 Aug 2016 16:22:06 -0400 (EDT)
From: "Mark K. Miller" <max at psu.edu>
To: Shib Users <users at shibboleth.net>
Subject: assertion signing defaults for IdP v3 vs v2
Message-ID:
<alpine.A52.2.02.1608181545310.6225994 at tr25n15.aset.psu.edu>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
So, I think I've navigated down the path of converting my legacy mode files to native v3 files (which seems like 'mostly' just the relying-party.xml file.) Along the way, I think I noticed two things that strike me as 'odd.' I'd greatly appreciate if those far more expert than myself could share their thoughts.
First, do I just not have a clue, or did the defaults for assertion signing change between v2 and v3. For the DefaultRelyingParty, the SAML2SSOProfile was set to signResponses="never" signAssertions="always"
(which I believe was the default config.) However, according to some observed behavior, and my interpretation of this page:
https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration#RelyingPartyConfiguration-SystemProfileDefaults
it seems that the v3 default is to sign responses, but not sign assertions.
Second, what 'forced my hand' about converting to native mode was an SP that couldn't handle SHA-2. Once converted to native mode, I followed the example for "Per-Profile Signing Algorithm" shown on this page:
https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration#SecurityConfiguration-SigningandEncryptionConfiguration
To my surprise, after activating that example code for the SP in question, it still didn't work! The SP only started to work again after I changed the SAML2.SSO bean in that example to look like this:
<bean parent="SAML2.SSO"
p:securityConfiguration-ref="SHA1SecurityConfig"
p:signAssertions="true" />
Obviously, this relates to an SP that is configured for signed assertions, but isn't checking response signatures.
Am I just too easily confused? Did I just completely miss any discussion/documentation about changing the signing defaults? If the defaults really did actually change, is there a pointer to something that could help me understand that choice?
Sure I understand how to configure this stuff back to how my v2 IdP worked, but is that the best choice to make?
Thanks,
Max
------------------------------
Message: 5
Date: Thu, 18 Aug 2016 20:31:23 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: RE: assertion signing defaults for IdP v3 vs v2
Message-ID:
<9846A6064BD102419D06814DD0D78DE1129F5996 at CIO-TNC-D2MBX02.osuad.osu.edu>
Content-Type: text/plain; charset="us-ascii"
> First, do I just not have a clue, or did the defaults for assertion
> signing change between v2 and v3.
http://marc.info/?t=147134482600001&r=1&w=2
> Obviously, this relates to an SP that is configured for signed
> assertions, but isn't checking response signatures.
If one is going to require one or the other, that's the wrong one to require. But nobody with a bug of that nature would have any hope of knowing any of reasons why, or care, so in effect, if you have that sort of bug, you've proven you shouldn't be implementing. It's useful as a signal of (in)competence.
> Am I just too easily confused? Did I just completely miss any
> discussion/documentation about changing the signing defaults?
I'll add it to the release notes.
-- Scott
------------------------------
Subject: Digest Footer
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
End of users Digest, Vol 62, Issue 101
**************************************
More information about the users
mailing list