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]] 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]<mailto:[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]<mailto:[email protected]>] Sent: Monday, October 24, 2016 11:45 AM To: Kevin Kane <[email protected]<mailto:[email protected]>> Cc: allseen-core <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: PermissionConfigurator also has a SignManifest method for this purpose. From: George Tang [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, October 24, 2016 11:19 AM To: Kevin Kane <[email protected]<mailto:[email protected]>> Cc: allseen-core <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: The manifest needs to be signed with the same private key that signed the certificate. From: George Tang [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, October 24, 2016 10:20 AM To: Kevin Kane <[email protected]<mailto:[email protected]>> Cc: allseen-core <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>] Sent: Saturday, October 22, 2016 9:38 AM To: Kevin Kane <[email protected]<mailto:[email protected]>> Cc: allseen-core <[email protected]<mailto:[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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of George Tang Sent: Thursday, October 20, 2016 9:09 PM To: allseen-core <[email protected]<mailto:[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
