https://github.com/osquery/osquery logo
Powered by
#kolide
Title
# kolide
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 PM
Yes, 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 PM
So, 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 PM
Okay cool that helps clarify
t

Tim Bosserman

03/15/2019, 7:43 PM
Now I’m trying to get authentication to actually work in Fleet.
z

zwass

03/15/2019, 7:44 PM
Can 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 PM
for nameID, you mean?
z

zwass

03/15/2019, 7:44 PM
correct
t

Tim Bosserman

03/15/2019, 7:44 PM
let me bring up my config and look at exactly how I have it setup. One moment….
z

zwass

03/15/2019, 7:45 PM
Are you currently seeing any error from Fleet?
t

Tim Bosserman

03/15/2019, 7:45 PM
yes, 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 PM
So you're still seeing the error "session missing for request"?
t

Tim Bosserman

03/15/2019, 7:47 PM
correct
z

zwass

03/15/2019, 7:47 PM
Okay cool I'll take a look into your notes again.
One more thing I notice: The assertion returned by Duo does not include an 
InResponseTo
element, which is required by the SAML spec and likely what is generating the "session missing" errors.
t

Tim Bosserman

03/15/2019, 8:04 PM
That’s very useful. I can add that to my ticket with Duo.
👍 1
z

zwass

03/15/2019, 8:05 PM
Maybe 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 PM
I 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 PM
Ha, 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 
InResponseTo
in Fleet's SSO login (in a custom build of Fleet).
t

Tim Bosserman

03/15/2019, 8:13 PM
I 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 PM
Looking at the code, I don't think you're going to get past the session error.
t

Tim Bosserman

03/15/2019, 8:18 PM
Yeah, same error. But it was worth it to make sure.
Copy code
{
  "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 PM
I'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 PM
From 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 PM
Can you give me the contents of the POST to Fleet from a Duo-initiated login?
t

Tim Bosserman

03/15/2019, 8:25 PM
sure, gimme a minute….
want me to attach it here or to the github issue?
z

zwass

03/15/2019, 8:26 PM
Github issue please.
t

Tim Bosserman

03/15/2019, 8:26 PM
will 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 PM
Yes, 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 PM
got it
z

zwass

03/15/2019, 8:52 PM
t

Tim Bosserman

03/15/2019, 8:52 PM
Thank you.
z

zwass

03/15/2019, 8:54 PM
Now, 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 
InResponseTo
. There's some discussion about this here: https://security.stackexchange.com/questions/42354/do-i-have-to-validate-saml2-inresponseto
Auth0 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 
InResponseTo
would be considered legitimate, while existing requests would be validated as they are. I would really like to get some validation from someone else that this seems to be a correct interpretation of how IdP-initiated login needs to be handled from the SP perspective.
t

Tim Bosserman

03/15/2019, 9:15 PM
If / when I get a response from Duo, I’ll paste something into the github issue.
z

zwass

03/15/2019, 9:15 PM
Nice, thanks Tim.
t

Tim Bosserman

03/15/2019, 9:15 PM
I’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 PM
I just added some notes in the Github issue that may be helpful
t

Tim Bosserman

03/15/2019, 9:15 PM
Thanks.
oh, terrific!
z

zwass

03/15/2019, 9:16 PM
fwiw 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 PM
That 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 PM
No 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 PM
We’ll see what happens with that….
Powered by