On Thursday, January 9, 2014, Mark Adamcin wrote: > 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?
That is correct. It's a problem shared by all AuthenticationHandlers.. Best regards Ian > > Mark Adamcin > http://adamcin.net/ > > > On Thu, Jan 9, 2014 at 12:35 AM, Tommaso Teofili > <[email protected] <javascript:;>>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 > > > > >> >
