Hi Mark, that looks nice! Being able to reuse that for Sling Replication authentication would really help, looking forward to see this being available in Sling.
Regards, Tommaso 2014/1/8 Mark Adamcin <[email protected]> > 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/ > > >> > > >
