Yes, that's correct. And the httpsig OSGi bundle should be ASL compatible from top-to-bottom, though I would appreciate having a second look at the BouncyCastle embeds, which I identify in a NOTICE.txt file within the bundle.
Mark Adamcin http://adamcin.net/ On Wed, Jan 8, 2014 at 11:14 AM, Justin Edelson <[email protected]>wrote: > 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/ > >> >
