I classify this as a part of Security 2.0 functionality that isn't available on Java. My reasoning is since manifest isn't a datatype allowed on java and while there is a function in Permission configurator to sign a manifest datatype, there isn't one to sign a string manifest.
I think this is low - medium effort. 8 hours not including a code review. If this isn't added, there isn't a very clear way to call SecurityApplicationProxy Reset, or StartManagement, or EndManagement. On Tue, Oct 25, 2016 at 10:02 AM, Josh Spain <[email protected]> wrote: > 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 > >
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
