[
https://issues.apache.org/jira/browse/PROTON-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530073#comment-13530073
]
Philip Harvey commented on PROTON-181:
--------------------------------------
I propose that we increase the scope of this Jira.
I'd like the remaining per-session setter functions
(pn_ssl_set_peer_authentication and pn_ssl_allow_unsecured_client) to be moved
to the new SSL domain object. My reasons for preferring this are:
- It is more convenient for the host application to set these details once on
the SSL domain than on every SSL session.
- If different settings are required for a particular session, then the host
application could just create a new SSL domain. This feels more natural than
having an interplay of default/override settings on the domain and the session
respectively.
- If we only allow peer authentication to be configured on an SSL domain, and
not on each session, it allows proton-j to maintain a one-to-one mapping
between a Proton SSL domain and a java SSLContext, thus making our
implementation simpler. If we do this, it would feel natural to move peer
authentication to SSL domain too.
> SSL layer - deprecate old per-connection credentials API, introduce new
> top-level configuration domain
> ------------------------------------------------------------------------------------------------------
>
> Key: PROTON-181
> URL: https://issues.apache.org/jira/browse/PROTON-181
> Project: Qpid Proton
> Issue Type: Wish
> Components: proton-c, proton-j
> Affects Versions: 0.2
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Fix For: 0.3
>
>
> In the first two releases of the SSL layer, the model only provided a
> per-connection object (pn_ssl_t). Thus, all configuration had to be applied
> each time an SSL connection was created.
> As new capabilities were added to SSL, this model has proven to be
> inadequate.
> With session resume, a new top-level object was introduced: pn_ssl_domain_t.
> This object becomes a "factory" for pn_ssl_t connections. Common
> configuration, such as credentials and CA database, are configured at the
> pn_ssl_domain_t level, and are adopted by each connection (pn_ssl_t) that is
> created.
> This model not only reduces the configuration actions need by the app, but
> results in a cleaner SSL implementation since the underlying SSL libraries
> (OpenSSL and Java's SSL) use a very similar model.
> More detail of the new api can be seen in PROTON-136.
> The problem now become support of the old api. Behavior becomes a bit vague
> if we allow credential, etc, configuration on both the domain and the ssl
> connection. Given the brief exposure of the existing api, we'd like to drop
> support for the following existing SSL API methods:
> pn_ssl() - constructor
> pn_ssl_init()
> pn_ssl_set_credentials()
> pn_ssl_set_trusted_ca_db()
> The corresponding functionality would instead be available via the
> domain-based api.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
