Thanks Noah, that's a good point. Based on the discussion I can't tell if there's a workaround or if part of Security 2.0 functionality on Java is absent. If it's the latter then we have to fix it, if it's the former then we need a compelling argument as Kevin said.
@George, @Kevin, what is the level of effort and risk on this, and how important is it? Thanks, Josh Josh Spain Director of Engineering Affinegy, Inc. t.512-535-1700 x1006 a. 1705 S Capital of Texas Hwy, Suite 310, Austin, TX 78746 USA Website <http://affinegy.com> Email <[email protected]> <http://www.linkedin.com/in/joshspain> <http://twitter.com/affinegy> Latest Tweet: <https://twitter.com/Affinegy> The @LeEcoGlobal <https://twitter.com/LeEcoGlobal> North America debut here - https://t.co/DGgEcFHxNY. Labeled #odd <https://twitter.com/odd> by many sources, but #bold <https://twitter.com/bold> nonetheless.. Read More <https://twitter.com/Affinegy/statuses/790163224779853824> <https://twitter.com/Affinegy> On Mon, Oct 24, 2016 at 10:41 PM, Noah Harlan <[email protected]> wrote: > Fwiw: if it doesn't go in now then it won't ever be in the certified base > implementation so it might be worth querying if never having it is > preferable. 16.10 is the last certified base implementation. > > --------------------- > Noah Harlan > Sent from a portable device > Typos are courtesy of big thumbs > > On Oct 24, 2016, at 5:07 PM, Kevin Kane via Allseen-core < > [email protected]> wrote: > > It’s an API change, which is no small thing. I think you have to argue the > need for it is compelling enough to allow it at this late point in the > release cycle. > > > > *From:* George Tang [mailto:[email protected] <[email protected]>] > *Sent:* Monday, October 24, 2016 12:49 PM > *To:* Kevin Kane <[email protected]> > *Cc:* allseen-core <[email protected]> > *Subject:* RE: [Allseen-core] ER_PERMISSION_DENIED > > > > I'm fine with this. Would this be a problem since it's a code freeze? > > > > On Oct 24, 2016 1:48 PM, "Kevin Kane" <[email protected]> wrote: > > Ah, that’s a good point. > > > > This may be an artifact of unit test code previously using bus attachments > to sign certificates and manifests as a convenient way to generate and use > public/private key pairs. The SecurityApplicationProxy methods are designed > to work with XML strings, but they require providing the signing key as a > parameter. > > > > I think you’ve identified a gap in the API. Personally I think it’s poor > design for a security manager to use a bus attachment as a key container, > but the convenience of doing so (as opposed to implementing some external > storage method for keys) seems to be too compelling. > > > > The solution could be to add overloads to C++ PermissionConfigurator’s > SignManifest method to allow it to operate on XML strings, the same way > SecurityApplicationProxy’s do, and then exposing those through to the Java > layer. We generally want to move to XML-using APIs. What do you think? > > > > > > *From:* George Tang [mailto:[email protected]] > *Sent:* Monday, October 24, 2016 11:45 AM > *To:* Kevin Kane <[email protected]> > *Cc:* allseen-core <[email protected]> > *Subject:* Re: [Allseen-core] ER_PERMISSION_DENIED > > > > I didn't expose this function to the Java side, because that would expose > the manifest datatype. There didn't seem to be a sign manifest for string. > Is the solution exposing a java one specifically with a string manifest > parameter, doing the conversions in the JNI layer, and returning a string? > > > > I have taken a look a XmlManifestConverter, and I don't it is public, so I > don't think I would be able to use existing infrastructure to do this. > > > > On Mon, Oct 24, 2016 at 1:26 PM, Kevin Kane <[email protected]> wrote: > > PermissionConfigurator also has a SignManifest method for this purpose. > > > > *From:* George Tang [mailto:[email protected]] > *Sent:* Monday, October 24, 2016 11:19 AM > > > *To:* Kevin Kane <[email protected]> > *Cc:* allseen-core <[email protected]> > *Subject:* Re: [Allseen-core] ER_PERMISSION_DENIED > > > > When the certificates are signed with the generated private key instead of > by PermissionConfigurator.sign from the bus attachment, calling claim will > give me an ER_INVALID_CERTIFICATE. > > > > Since CredentialAccessor isn't public, the security manager sample > shouldn't be able to get the bus private key either. I'm curious if the > security manager uses the bus's permission configurators to sign the > certificate. and how it gets the private key to sign the manifest. > > > > On Mon, Oct 24, 2016 at 12:37 PM, Kevin Kane <[email protected]> wrote: > > The manifest needs to be signed with the same private key that signed the > certificate. > > > > *From:* George Tang [mailto:[email protected]] > *Sent:* Monday, October 24, 2016 10:20 AM > > > *To:* Kevin Kane <[email protected]> > *Cc:* allseen-core <[email protected]> > *Subject:* Re: [Allseen-core] ER_PERMISSION_DENIED > > > > After adding the SecureConnection call on the bus attachments, there is a > SendManifests call. However, another error before the reset > ER_PERMISSION_DENIED, manifest signature failed to verify. Since I am > signing the manifests with a generated private key and not the bus's > private key from credential accessor, are there any fields in the > certificate that I need to change to the generated public key? Do I need to > sign the certificates with the generated private key too instead of with > the bus's permission configurator? I have attached the new log. > > > > Thanks, > > George > > > > On Mon, Oct 24, 2016 at 10:35 AM, Kevin Kane <[email protected]> wrote: > > Is your test also calling SecureConnection(true) on the bus attachment > after Claim so that the ECDSA session is established? Otherwise the manager > bus will try to continue with the existing ECHDE_NULL session and the > method calls will fail. > > > > *From:* George Tang [mailto:[email protected]] > *Sent:* Saturday, October 22, 2016 9:38 AM > *To:* Kevin Kane <[email protected]> > *Cc:* allseen-core <[email protected]> > *Subject:* Re: [Allseen-core] ER_PERMISSION_DENIED > > > > Hi Kevin, > > > > The logs contain a call to installMembership on the manager bus. Are there > any other reasons for not having a sendMemberships call? When writing these > tests I could not use credential accessor to get the guid of the bus to set > the IssuerCN, and I could not use it to get the bus privatekey to sign the > manifest. So I generated a random private key and a random guid instead. > > > > Thanks, > > George > > > > On Fri, Oct 21, 2016 at 10:20 AM, Kevin Kane <[email protected]> wrote: > > I don’t see any calls to SendMemberships in the trace. This suggests your > security manager bus attachment hasn’t been provisioned with an admin group > membership certificate, since later the PERMISSION_MGMT source shows the > peer does not match against the ACL for WITH_MEMBERSHP, which should match. > Can you make sure your setup generates and installs an admin group > membership certificate onto the bus attachment from which you make the > Reset call? > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *George Tang > *Sent:* Thursday, October 20, 2016 9:09 PM > *To:* allseen-core <[email protected]> > *Subject:* [Allseen-core] ER_PERMISSION_DENIED > > > > Hi all, > > > > I am getting this error ER_PERMISSION_DENIED, when calling reset in Java. > I have a feeling that some value of CertificateX509 is not being set > correctly, but I don't know which value. I have the logs for a successful > call to reset from the core sample test SecurityClaimApplicationTest.cc > (testlog). I also have logs the call to reset from the Java bindings that > fails (antlog). It would be great if someone experienced in security and > certificates could take a look. > > > > Thanks, > > George > > > > > > > > > > _______________________________________________ > Allseen-core mailing list > [email protected] > https://lists.allseenalliance.org/mailman/listinfo/allseen-core > > > _______________________________________________ > Allseen-core mailing list > [email protected] > https://lists.allseenalliance.org/mailman/listinfo/allseen-core > >
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
