-
Notifications
You must be signed in to change notification settings - Fork 35
Santa Client Certificate Authentication #31
Comments
btw I'm going forward with a variation of http signatures: https://tools.ietf.org/html/draft-cavage-http-signatures-10, much like AWS API Auth |
btw, from what I read client auth may be possible if this project moves to be a "flexible" GAE project |
Sounds good! How are you planning on attaching the header to the client requests? Client-side proxy? And yes mTLS is a possibility with flex but the migration is non-trivial (I believe datastore and memcache interfaces change substantially). |
we're planning on modifying the santa binary since we want to change the branding anyways so users aren't presented with "santa" popups, and rather some form of corporate security :) That's an interesting idea though of the proxy, thanks! I'll post a link here later with our changes to santa. I already have most of the changes done, unfortunately I've been battling the calendar API for a LONG time due to a variety of issues. If you happen to have any contacts with the calendar API team it would be appreciated! |
nitpick: that would be Santa binaries, the pop-ups come from Santa.app, syncing is done by santactl. Also, Santa has configuration options so you can customize some of the messaging. We had plans to make the entire UI customizable but the engineering effort involved coupled with the way the resulting UI worked (decidedly non-native and with subpar accessibility) resulted in us abandoning those plans. |
yes ty! So changing santa app for UI and santactl for auth. We wanted to mostly change the titles of the dialogs. I'd imagine most of it could be done with some form of custom resource (its been awhile since I've done native OS-X, will report back). |
ok I have initial code done: right now it's geared towards our company, however it can be generalized. We'll test in our org it as soon as we get our kext cert approved by Apple. For now via debugger seems to work ok with our prod upvote server. |
Hello all, I realize I'm necroing an old thread—would it be more appropriate to start another issue regarding expanding Upvote's ValidateClient() stub to more readily implement mTLS or would continuing this thread be preferred? We want to generally recommend to our admins that they use client authentication with mTLS when using Santa/Upvote, but the need to implement a validation function makes that out of reach for many. It's unclear to me if the GAE project type remains a hurdle still, but properly directing any interest that might exist to do this work seems wise. Thanks! |
so per the santa docs, the way one is supposed to lock down santad<->upvote communication is via server based client certificate auth. Unfortunately, after looking at
ValidateClient
, it seems some sort of header token auth is instead expected by upvote.I looked a little bit into implementing client certificate auth however it seems webapp2 does not support this, nor does the GAE environment in general. What method of santa<->upvote auth do the authors of upvote expect end-users to implement to be secure?
The text was updated successfully, but these errors were encountered: