[connector-spec-users] [jsr322-experts] Re: Supporting password aliases in Confidential Properties and the Password Property
Hi Siva,
> Could we say that if an application server supports
> confidential properties, it must support resolving password aliases.
Agree.
Thanks
Wilson
> -----Original Message-----
> From: Sivakumar Thyagarajan
> Sent: Thursday, December 06, 2012 11:24 PM
> To: jsr322-experts_at_connector-spec.java.net
> Cc: Wilson Tian
> Subject: [jsr322-experts] Re: Supporting password aliases in Confidential Properties and the Password Property
>
> Hi Wilson
>
> On Thursday 06 December 2012 12:35 PM, Wilson Tian wrote:
> > If password alias support will be mandatory for AS, should
> > confidential properties support also be marked as mandatory for AS?
> > IIUC, confidential properties is a optional feature to both adapters
> > and AS in Connector 1.6.
>
> I don't think requiring support for resolving password aliases in a confidential property requires the
> application server to support confidential property. Could we say that if an application server supports
> confidential properties, it must support resolving password aliases.
>
> In Connector 1.6, we did not get enough interest in mandating this, as the real visible semantic of a
> confidential property is how it is treated in tools/UI etc, which wasn't specified clearly anyway.
>
> Does anyone think that we must standardize the support for confidential properties?
>
> > Also, the proposal for section 5.3.7.6 uses 'is responsible for', does
> > it mean 'must'? may be reworded to make it clearer.
>
> Agreed, thanks.
>
> > A minor suggestion: add 'AdministeredObject' to the 'Impact' section:
> > *Impact* With this change, while a value for a configuration property
> > for a JavaBean such as Resource Adapter, MCF, AdministeredObject or
> > ActivationSpec is specified by a user>
>
> Good catch. Sure, I will include this.
>
> Thanks
> --Siva.
>
> > Thanks
> > Wilson
> >
> >
> >> -----Original Message-----
> >> From: Sivakumar Thyagarajan
> >> Sent: Wednesday, December 05, 2012 11:49 PM
> >> To: jsr322-experts_at_connector-spec.java.net
> >> Cc: Jesper Pedersen
> >> Subject: [jsr322-experts] Re: Supporting password aliases in
> >> Confidential Properties and the Password Property
> >>
> >> Hi Jesper
> >>
> >> On Tuesday 04 December 2012 07:36 PM, Jesper Pedersen wrote:
> >>> Hi,
> >>>
> >>> On 12/03/2012 10:53 PM, Sivakumar Thyagarajan wrote:
> >>>> Could we require application servers to support the specification
> >>>> (and
> >>>> resolution) of Password aliases in all Configuration Properties of
> >>>> a JavaBean that are marked as confidential, and the standard "Password"
> >>>> Configuration Property?
> >>>>
> >>>> *Impact*
> >>>> With this change, while a value for a configuration property for a
> >>>> JavaBean such as Resource Adapter, MCF or ActivationSpec is
> >>>> specified by a user, the user could use a password alias. The
> >>>> application server is required to resolve this alias and pass the
> >>>> resolved plain-text password to the resource adapter.
> >>>>
> >>>> *Spec Impact*
> >>>> Section 5.3.7.6: Add the following lines: "A Password alias may be
> >>>> used while configuring confidential properties. The application
> >>>> server is responsible for resolving the alias and passing the clear
> >>>> text password to the JavaBean. For more details on the Password
> >>>> Alias feature and its format, see Section EE.3.7 "Password Aliasing
> >>>> and Management" of the Java EE 7 platform specification."
> >>>>
> >>>> Section 20.5.4: Add the following lines: "The application server
> >>>> must support the specification of password aliases in the Password
> >>>> standard Property. For more details on the Password Alias feature
> >>>> and its format, see Section EE.3.7 "Password Aliasing and
> >>>> Management" of the Java EE 7 platform specification"
> >>>>
> >>>
> >>> I agree with this change.
> >>>
> >>> However, you can't make it a mandatory requirement, since existing
> >>> certified implementations doesn't support this feature.
> >>
> >> A spec usually goes through two types of changes through the MR process:
> >> - Errata: These are small changes to a spec that don't change the
> >> meaning of the spec(typos, fixing obvious inconsistencies in the
> >> spec, clarifications). In most cases, an errata should not require a change to the implementation or the TCK.
> This does not require a new spec version.
> >> In this case we can't bring in new features that existing certified implementations cannot support.
> >> - API Changes: These are changes that change the meaning of the spec,
> >> adds features etc. This could be API signature changes (adding a
> >> class, method), behavior changes, requirement changes. The
> >> requirement is that such changes are backward compatible with the
> >> previous version of the specification. These changes results in new
> >> assertions, a new spec version (Connectors 1.7 in our case), new TCK
> >> version etc. A EE7 implementation must support this new Connector
> >> spec version (1.7) and hence there is no issue in adding features (as
> >> long as the added features are not backward compatible with the
> >> earlier version of the spec)
> >>
> >> In this MR that we are aiming for EE7, we would add new APIs (to
> >> support JMS/EJB changes, for the new resource definition
> >> annotations), and so we fall in the second category. So, I would like to suggest that this can remain as a
> "must".
> >>
> >> Thanks
> >> --Siva.
> >>
> >>> So change "must" to "may".
> >>>
> >>> File an issue for JCA.next to make it mandatory and adding a TCK
> >>> test for the functionality. In JCA.next the standalone environment
> >>> definition would need an update to make this feature optional
> >>> ("may"), since it isn't tied to the EE spec.
> >>>
> >>> Best regards,
> >>> Jesper
> >>>
> >>
>