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

Reply via email to