https://github.com/osquery/osquery logo
Join Slack
Powered by
<@U0JFM04MS>: Just saw your comment in github rega...
# kolide
t
@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
Yes, thank you.
Can you help me understand where in the process you are seeing an error at this point?
t
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
Okay cool that helps clarify
t
Now I’m trying to get authentication to actually work in Fleet.
z
Can you configure Duo to send email instead of username?
I notice we are getting a username when we expect email.
t
for nameID, you mean?
z
correct
t
let me bring up my config and look at exactly how I have it setup. One moment….
z
Are you currently seeing any error from Fleet?
t
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
So you're still seeing the error "session missing for request"?
t
correct
z
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
That’s very useful. I can add that to my ticket with Duo.
👍 1
z
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
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
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
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
Looking at the code, I don't think you're going to get past the session error.
t
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
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
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
Can you give me the contents of the POST to Fleet from a Duo-initiated login?
t
sure, gimme a minute….
want me to attach it here or to the github issue?
z
Github issue please.
t
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
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
got it
z
t
Thank you.
z
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
If / when I get a response from Duo, I’ll paste something into the github issue.
z
Nice, thanks Tim.
t
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
I just added some notes in the Github issue that may be helpful
t
Thanks.
oh, terrific!
z
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
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
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
We’ll see what happens with that….
Open in Slack
PreviousNext
Powered by