Mark- Unless I'm missing something, clients (whether those running inside Sling or standalone) would use httpsig-java's API, not the auth handler. Correct?
In any case, I think just moving the auth handler into Sling is OK, as long as the license on the httpsig-java bundle permits us to include it with launchpad (which I believe it does). Regards, Justin On Wed, Jan 8, 2014 at 2:05 PM, Mark Adamcin <[email protected]> wrote: > Hi Justin, > > I'm already managing the httpsig-java code and documentation in GitHub, > using Travis CI, and releasing to Maven Central under my own groupId, so I > don't think there is a pressing need for that to be moved to ASF, but I'm > certainly open to learning the finer details of IP management. > > The Sling AuthenticationHandler is just one service and could easily be > moved into Sling somewhere, perhaps as part of a combined > org.apache.sling.auth.httpsig bundle, which would also export the API for > use by internal HTTP clients, like replication agents and topology > connectors. > > > Mark Adamcin > http://adamcin.net/ > > > On Wed, Jan 8, 2014 at 9:55 AM, Justin Edelson > <[email protected]>wrote: > >> Hi Mark, >> This is very cool. >> >> I think adding this authentication handler into Sling makes sense. I'm >> not sure that this is the best place for the core signature code >> itself -- maybe that should be a separate ASF project? Don't get me >> wrong - I don't *mind* it being in Sling, but it seems like something >> which has very broad applicability. >> >> If you have the Authentication Handler in place, that should cover all >> of the server parts you mentioned. The harder work is going to be >> adding it to the clients. >> >> Justin >> >> On Wed, Jan 8, 2014 at 12:33 PM, Mark Adamcin <[email protected]> wrote: >> > Hi Sling devs, >> > >> > I recently released a Java implementation [1] of Joyent's HTTP Signature >> > authentication scheme [2] based on SSH authorized_keys login. >> > >> > The intended purpose of this draft authentication scheme is really to >> > provide a slightly more secure alternative to Basic and Digest >> > authentication [RFC2617] as a convenient (stateless) client-server >> > protocol, and is not meant to replace SSO, OAuth or other forms of >> > negotiated token authentication or authorization schemes. >> > >> > My involvement in this project originated as a solution to the problem of >> > managing a multi-tier and multi-owner CQ installation in a way that >> avoids >> > the issues associated with sharing admin passwords between application >> > instances and between operations, infrastructure, and DevOps groups. And >> by >> > using OpenSSH-style authorized_keys, I recognized a natural fit for >> > implementing support in popular CI and IT automation stacks like Jenkins, >> > Chef, and Puppet. >> > >> > Conceptually, the scheme works this way: >> > >> > 1. a server has access to an SSH authorized_keys file on the filesystem, >> > located at ~/.ssh/authorized_keys by default >> > 2. an HTTP client similarly has access to a PEM-encoded SSH private key >> > file, located at ~/.ssh/id_rsa by default >> > 3. For each HTTP request, the client adds an authorization header with >> the >> > ID of the private key (incorporating both the Sling user Id and the >> public >> > key fingerprint), a base-64 encoded RSA signature, and a listing of the >> > request headers that were signed. >> > 4. The server verifies the signature in the request by looking up the >> > principal and the associated public key, which it then uses to verify the >> > signature against the identified headers. >> > >> > My first practical use of this implementation is built into the CRX >> Content >> > Package Deployer Plugin for Jenkins [3]. In addition to supporting the >> > normal username/password login through j_security_check, it also supports >> > Signature authentication using Jenkins SSH Private Key credentials. To >> > enable support on the server side, you may follow the steps outlined here >> > [4] to install a Sling HTTP Signature AuthenticationHandler that enables >> > Signature login as the admin user. >> > >> > I'd like to make this scheme usable in Sling out-of-the-box; specifically >> > for: >> > >> > * Bundle deployment and configuration management (Felix Admin Console, >> > maven-sling-plugin, Sling AuthenticationHandler) >> > * Replication >> > * Discovery (this already supports a similar signature scheme using hmac) >> > * vlt/davex (these aren't sling projects, but you can see where I'm going >> > with this) >> > >> > I've released all the code into the public domain, so there shouldn't be >> > any license issues with repurposing the source if necessary. The >> > httpsig-ssh-bc module depends on a couple BouncyCastle binaries for >> reading >> > PEM-encoded private keys, which are also embedded in the >> > net.adamcin.httpsig.osgi bundle, but those binaries should be >> > ASL-compatible if they aren't already embedded elsewhere in Sling. >> > >> > I'd be happy to get directly involved in designing and implementing this >> if >> > there is interest in the concept. Does this sound like a worthwhile >> > endeavor? >> > >> > [1] https://github.com/adamcin/httpsig-java >> > [2] >> > >> https://github.com/joyent/node-http-signature/blob/master/http_signing.md >> > [3] >> > >> https://wiki.jenkins-ci.org/display/JENKINS/CRX+Content+Package+Deployer+Plugin >> > [4] >> > >> https://github.com/adamcin/net.adamcin.sling.auth.httpsig/wiki/getting-started >> > >> > Mark Adamcin >> > Acquity Group >> > http://adamcin.net/ >>
