One of the outstanding concerns I have with my first implementation of this Sling AuthenticationHandler is that it relies on Jackrabbit Token Auth for getting a ResourceResolver. This requires a bundle dependency on jackrabbit-api.
Instead, this auth handler would ideally establish trust by whatever means ends up being implemented in regards to this discussion: https://cwiki.apache.org/confluence/display/SLING/Solving+the+Authentication+Handler+Credential+Validation+Problem Am I correct in that assumption? Mark Adamcin http://adamcin.net/ On Thu, Jan 9, 2014 at 12:35 AM, Tommaso Teofili <[email protected]>wrote: > 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/ > > > >> > > > > > >
