Channels
android_tests
apple-silicon
arm-architecture
auditing-warroom
aws
carving
code-review
community-feeds
core
darkbytes
doorman
ebpf
eclecticiq-polylogyx-extension
extensions
file-carving
fim
fleet
fleet-dev
fleetosquery
foundation
fuzzing
general
golang
goquery
infrastructure
jobs
kolide
linen-dev
linux
macos
officehours
osctrl
plugins
process-auditing
querycon
queryhub
random
selfgroup
sql
tls
uptycs
vendor-feeds
website
windows
zeek
zentral
zercurity
Title
t
Tim Bosserman
03/15/2019, 7:42 PM@zwass: Just saw your comment in github regarding my issue (SAML authentication appears to not work with Duo IdP -- #2004). Did I manage to come to the right place?
z
zwass
03/15/2019, 7:43 PMYes, thank you.
Can you help me understand where in the process you are seeing an error at this point?
t
Tim Bosserman
03/15/2019, 7:43 PMSo, since I opened the original ticket, I opened a ticket with Duo. They helped me find a config change to make on the Fleet side which eliminated the errors I was getting in Duo.
z
zwass
03/15/2019, 7:43 PMOkay cool that helps clarify
t
Tim Bosserman
03/15/2019, 7:43 PMNow I’m trying to get authentication to actually work in Fleet.
z
zwass
03/15/2019, 7:44 PMCan you configure Duo to send email instead of username?
I notice we are getting a username when we expect email.
t
Tim Bosserman
03/15/2019, 7:44 PMfor nameID, you mean?
z
zwass
03/15/2019, 7:44 PMcorrect
t
Tim Bosserman
03/15/2019, 7:44 PMlet me bring up my config and look at exactly how I have it setup. One moment….
z
zwass
03/15/2019, 7:45 PMCheck out https://github.com/kolide/fleet/blob/master/docs/dashboard/single-sign-on.md#identity-provider-idp-configuration. The section "Name ID Format"
Are you currently seeing any error from Fleet?
t
Tim Bosserman
03/15/2019, 7:45 PMyes, I think I listed the errors its logging in the github issue
but I see that I’m sending just the username, not email. So let me change that and see what that does.
I’ve actually tried it both ways out of semi-desperation, but I see that I left it at “unspecified” instead of “email”.
I’ll ping you back in a few. This will take me about 15 minutes to change and push out.
z
zwass
03/15/2019, 7:47 PMSo you're still seeing the error "session missing for request"?
t
Tim Bosserman
03/15/2019, 7:47 PMcorrect
z
zwass
03/15/2019, 7:47 PMOkay cool I'll take a look into your notes again.
One more thing I notice: The assertion returned by Duo does not include an
InResponseToSee the spec (https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf) line 1601.
t
Tim Bosserman
03/15/2019, 8:04 PMThat’s very useful. I can add that to my ticket with Duo.
👍 1
z
zwass
03/15/2019, 8:05 PMMaybe this is something you can bring up with the Duo folks? It's possible we misread the spec but I think it's pretty clear.
t
Tim Bosserman
03/15/2019, 8:05 PMI will definitely add that to the ticket and see what they have to say.
Unfortunately, even if they acknowledge that it’s a bug, it will be awhile before I ever see a fix pushed out.
But I’ll definitely pursue that.
As I’m sure you know very well, the SAML specs are so “voluminous” that I doubt ANYBODY really knows them thoroughly. Except for maybe the Shibboleth folks 🙂
I’ve only been at this for about 18 months, which in relative terms makes me an “expert”, but I figure I still only know a tiny percentage of the spec
z
zwass
03/15/2019, 8:12 PMHa, no doubt. I didn't implement Fleet's SSO but I did significant code review and only know a tiny slice of the specs due to that.
If you are able to reason about the security of doing so, you could edit out the check for
InResponseTot
Tim Bosserman
03/15/2019, 8:13 PMI may do that just as a test to see if it makes things work for us.
I doubt we’d want to create our own “fork” just for this.
But it would give me more detail to add to the Duo ticket
I’m just about done launching the new Duo IdP instances with the nameID set to email. Will be testing in a moment….
z
zwass
03/15/2019, 8:16 PMLooking at the code, I don't think you're going to get past the session error.
t
Tim Bosserman
03/15/2019, 8:18 PMYeah, same error. But it was worth it to make sure.
{
"component": "service",
"err": "validation failed: session missing for request",
"method": "CallbackSSO",
"took": "585.133µs",
"ts": "2019-03-15T20:17:46.258744406Z"
}OK, thank you for your time. At this point, I’m going to update my Duo ticket, and perhaps do a custom build of Fleet with that check commented out to see if that makes it work.
Then I can report that back to the team that actually manages the Fleet server and let them decide what they want to do (assuming that everything works then).
z
zwass
03/15/2019, 8:19 PMI'd be curious if that makes it work. I'm also going to take another look at the spec to see what would be required to support IdP-initiated login. This likely avoids the bug(?) on Duo's end.
t
Tim Bosserman
03/15/2019, 8:20 PMFrom a purely selfish point of view, I’d love to see Fleet support IdP-initiated logins 🙂
But that’s not a deal breaker for me. As long as I can give the guys a way to authenticate that works….
z
zwass
03/15/2019, 8:23 PMCan you give me the contents of the POST to Fleet from a Duo-initiated login?
t
Tim Bosserman
03/15/2019, 8:25 PMsure, gimme a minute….
want me to attach it here or to the github issue?
z
zwass
03/15/2019, 8:26 PMGithub issue please.
t
Tim Bosserman
03/15/2019, 8:26 PMwill do
added to the ticket
btw, did you notice that InResponseTo is explicitly listed as an optional StatusResponseType in the spec that you pointed me to?
Anyway, I opened a new ticket with Duo, and added all this info into the ticket. I’ll be curious to see what they have to say.
z
zwass
03/15/2019, 8:51 PMYes, but that seems to be because in some cases it would not be required. In our case the standard makes it clear that it is required.
t
Tim Bosserman
03/15/2019, 8:51 PMgot it
z
zwass
03/15/2019, 8:52 PMt
Tim Bosserman
03/15/2019, 8:52 PMThank you.
z
zwass
03/15/2019, 8:54 PMNow, what I'm trying to understand is why it is required. Because it looks like an IdP initiated login is basically the same response but without an
InResponseToAuth0 also has some comments on this at https://auth0.com/docs/protocols/saml/idp-initiated-sso
Given all of this research I think it would be reasonable to add an option to support an IdP initiated login. If this were enabled, a request without
InResponseTot
Tim Bosserman
03/15/2019, 9:15 PMIf / when I get a response from Duo, I’ll paste something into the github issue.
z
zwass
03/15/2019, 9:15 PMNice, thanks Tim.
t
Tim Bosserman
03/15/2019, 9:15 PMI’m in the process of transcribing all this stuff that we discussed so I don’t have to “dumpster-dive” for it later!
z
zwass
03/15/2019, 9:15 PMI just added some notes in the Github issue that may be helpful
t
Tim Bosserman
03/15/2019, 9:15 PMThanks.
oh, terrific!
z
zwass
03/15/2019, 9:16 PMfwiw I also suspect that commenting out the check for the session would allow Duo-initiated login if you want to try a custom build.
t
Tim Bosserman
03/15/2019, 9:16 PMThat was the stuff I was transcribing
Yeah, I’ll get to that as soon as I have the time to spare.
There’s nothing wrong with me linking to the github issue in the Duo ticket, is there?
z
zwass
03/15/2019, 9:17 PMNo problem for me. That Github is public and free to link.
I'm happy to engage directly with Duo folks there if they are interested.
t
Tim Bosserman
03/15/2019, 9:18 PMWe’ll see what happens with that….