All,
The *clientSecret* is a concept of OAuth2 (within the authorization code
grant flow) which needs to be kept secret, just as a password.
So that is a candidate for the password Aliasing concept.
Best regards
Rudy
On 18 November 2016 at 23:16, Will Hopkins <will.hopkins_at_oracle.com> wrote:
> Werner,
>
> The attachment did make it through.
>
> My take is it's premature to say that OAuth/OpenID Connect will be in EE
> 8. There's been some discussion about it internally, and I was asked to
> get a sense of how the EG felt about it, but it's by no means a given that
> we'll move forward with it, especially given its size and complexity
> relative to the time frame of EE 8.
>
> I would also note that "Secret Management (incl. Password Aliasing)" would
> presumably remain in EE.next even if OAuth moved to EE 8 -- or do you see
> an OAuth dependency on secret management?
>
> Will
>
> On 11/18/2016 01:57 PM, Werner Keil wrote:
>
> Dear Experts,
>
> Please find a link to my recent Java2Days talk (the smaller room was
> packed, people even stood in the back, it could have filled the bigger one,
> too if it was held there;-) about Java EE Security for Java EE 8 and 9.
>
> http://www.slideshare.net/keilw/java2days-security-for-
> javaee-and-the-cloud
>
> The topics and especially the roadmap I presented was largely based on
> KK's JavaOne presentation. After talking to Dmitry he suggested it's good
> to also keep the disclaimer (Rudy had a slightly different one in his talk)
>
> Yesterday (the last day seemed a lot less crowded, especially talks around
> the end e.g. on CDI 2 were almost empty) David Delabasse talked about Java
> EE ".next" in general, also but not only Security. He certainly had the
> same disclaimer, so nothing is written in stone, but hinted, features like
> OAuth or OpenID Connect (essentially that means OAuth, since it's based on
> OAuth2) were "nice to have" in Java EE 8 already.
>
> So instead of the feature breakup and roadmap I have in my slides (or KK
> did before) this would look like the attached PDF taken from page 59. And
> only 2 features ("Security Microservices" and "Packaging") would be left
> for Java EE 9 while the lion share could or would end up in JSR 375 for
> Java EE 8.
>
> Do all of you think that's realistic?
> Don't forget especially the TCK unless a working java.net replacement
> allowed "collaborative development" in the sense of jcp.next 5 (successor
> to JSR 364) before next Summer will be up to Oracle because the current
> license for that is not Open Source, so TCKs of all EE JSRs except by Red
> Hat are not developed in the open and members of the EG even if we all were
> willing to help normally can't work on that.
>
> I hope attachments work, at least in the Google Groups alias? If not, I
> can resend it to those of you who are interesting in a direct mail, but you
> also get the idea from the Slideshare presentation, just shift all but the
> bottom 2 to "Java EE 8";-)
>
> Kind Regards,
>
> Werner
>
>
> --
> Will Hopkins | Platform Security Architect | +1.781.442.0310
> Oracle Cloud Application Foundation
> 35 Network Drive, Burlington, MA 01803
>
>