Date   

Re: Github Java EE organization memberschip

Will Hopkins
 

Hi Werner,

See my response to Rudy.

Will


On July 21, 2017 6:45:11 AM EDT, Werner Keil <werner.keil@...> wrote:
Yes, me, too please: https://github.com/orgs/javaee/teams/java-ee-security-team/members

Thanks,
Werner

--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

Will Hopkins
 

Yes, but, as noted in my mail announcing the move was complete, you'll need to sign the Oracle contributor agreement. I'm not sure what's up with that, and why simply being a member of the EG isn't sufficient, but that's what I'm being told is necessary.

https://javaee.github.io/CONTRIBUTING
http://www.oracle.com/technetwork/community/oca-486395.html

If signing the OCA is a problem for some reason, let me know, and I'll see if there are any other options. Given that you're on the EG and you've already made contributions, this seems silly.

Will


On July 21, 2017 5:08:24 AM EDT, Rudy De Busscher <rdebusscher@...> wrote:
Hi Will,

Can you also add me to the Java EE Organization and the "Java EE Security Team" just like all the other active EG members and contributors?

Thanks

Rudy


--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Github Java EE organization memberschip

Werner Keil
 


Github Java EE organization memberschip

Rudy De Busscher
 

Hi Will,

Can you also add me to the Java EE Organization and the "Java EE Security Team" just like all the other active EG members and contributors?

Thanks

Rudy


Re: REPO MIGRATION COMPLETE

Rudy De Busscher
 

For correctness, these are the URLs

security-spec  (github.com/javaee/security-spec)
security-api  (github.com/javaee/security-api)
security-soteria  (github.com/javaee/security-soteria)
Best regards
Rudy

    On 21 July 2017 at 05:13, Will Hopkins <will.hopkins@...> wrote:
    The repo migration is complete. Please take the time to read this email completely, as it explains how access to the repos works now, and what you'll need to know/do in order to contribute going forward.
    • The following repos are now hosted by the Java EE organization:
    security-spec  (github.com/javaee/security-spec)
    security-api  (github.com/javaee/security-spec)
    security-soteria  (github.com/javaee/security-spec)
      • The security-api and security-soteria repos were transferred within github, so existing forks are still "connected", and existing clones should be redirected appropriately on push/pull. All commits, branches, tags, issues, etc., are intact. That said, it's probably a good idea to save any work in progress, delete existing forks/clones, and start fresh.
      • The security-spec repo was not transferred, instead it was cloned into an existing repo, with the same name, that already existed under the Java EE org. We lost the pull request history, but nothing else, AFAICT. All branches, commits, contributor information, etc., was carried over. You will need to recreate any existing forks or clones, or reconfigure them to point at the new repo. Access to the old security-spec repo has been disabled. I plan to delete it after the new repo has been "live" for a reasonable amount of time.
    • Access will work a little differently now:
      • For all three repos, members of the "Java EE Security Team" have write access to the repo. That means you can create branches, push to the repo, and create/update issues.
      • For the security-spec and security-api repos, the "master" branch is protected, so that only an organization or repo owner can push to it. I'm considering protecting the master branch of soteria such that pushing to master requires an approved review by someone with write access.
      • If you're not a member of the team, you can still submit a pull request or create an issue, but you won't be able to push changes or update issues. (And the pull request won't be accepted if you haven't signed the OCA, see below.)
      • Members of the team currently are myself, Arjan, Ivar, Alex Kosowski, and Ed Bratt. I have sent Guillermo an invitation to join the Java EE organization; assuming he accepts, he'll be added to the team as well.
    • If you intend to contribute, you MUST sign the OCA, and you SHOULD join the Java EE organization (for easier access):
      • All contributors must sign the Oracle Contributor Agreement (OCA), as explained here (http://www.oracle.com/technetwork/community/oca-486395.html). I was surprised to find that some EG members and "official" contributors (per the JCP site) aren't listed as having signed, including Werner, Rudy, and Ashley Richardson, apparently the OCA is distinct from what the JCP requires.
      • If you have signed the OCA and are a member of the Java EE organization, I'll add you to the "Java EE Security Team".
      • If you are not a member of the Java EE organization, and you'd like to be, and you've signed the OCA, let me know -- I'll send you an invite.
      • Note that that, when joining the Java EE organization, you are strongly encouraged, but not (yet) required, to:
        • Enable 2FA
        • Make your real name publicly visible
        • Update your avatar
    Thanks for paying attention this long. If you have questions or have trouble getting access to the repos, let me know.

    Regards,

    Will

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    



    LDAP memberOf Support

    Will Hopkins
     

    So I added support for group lookup via memberOf to the PFD version of the spec.

    Any EG members know whether it's possible to configure Unbounded or OpenDJ to support memberOf, and, if so, how? Need to write tests/TCK to cover this; starting to think it may require some ugly schema hacks to make it appear that memberOf is there and populated appropriately.

    Thanks,

    Will
    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    REPO MIGRATION COMPLETE

    Will Hopkins
     

    The repo migration is complete. Please take the time to read this email completely, as it explains how access to the repos works now, and what you'll need to know/do in order to contribute going forward.
    • The following repos are now hosted by the Java EE organization:
    security-spec  (github.com/javaee/security-spec)
    security-api  (github.com/javaee/security-spec)
    security-soteria  (github.com/javaee/security-spec)
      • The security-api and security-soteria repos were transferred within github, so existing forks are still "connected", and existing clones should be redirected appropriately on push/pull. All commits, branches, tags, issues, etc., are intact. That said, it's probably a good idea to save any work in progress, delete existing forks/clones, and start fresh.
      • The security-spec repo was not transferred, instead it was cloned into an existing repo, with the same name, that already existed under the Java EE org. We lost the pull request history, but nothing else, AFAICT. All branches, commits, contributor information, etc., was carried over. You will need to recreate any existing forks or clones, or reconfigure them to point at the new repo. Access to the old security-spec repo has been disabled. I plan to delete it after the new repo has been "live" for a reasonable amount of time.
    • Access will work a little differently now:
      • For all three repos, members of the "Java EE Security Team" have write access to the repo. That means you can create branches, push to the repo, and create/update issues.
      • For the security-spec and security-api repos, the "master" branch is protected, so that only an organization or repo owner can push to it. I'm considering protecting the master branch of soteria such that pushing to master requires an approved review by someone with write access.
      • If you're not a member of the team, you can still submit a pull request or create an issue, but you won't be able to push changes or update issues. (And the pull request won't be accepted if you haven't signed the OCA, see below.)
      • Members of the team currently are myself, Arjan, Ivar, Alex Kosowski, and Ed Bratt. I have sent Guillermo an invitation to join the Java EE organization; assuming he accepts, he'll be added to the team as well.
    • If you intend to contribute, you MUST sign the OCA, and you SHOULD join the Java EE organization (for easier access):
      • All contributors must sign the Oracle Contributor Agreement (OCA), as explained here (http://www.oracle.com/technetwork/community/oca-486395.html). I was surprised to find that some EG members and "official" contributors (per the JCP site) aren't listed as having signed, including Werner, Rudy, and Ashley Richardson, apparently the OCA is distinct from what the JCP requires.
      • If you have signed the OCA and are a member of the Java EE organization, I'll add you to the "Java EE Security Team".
      • If you are not a member of the Java EE organization, and you'd like to be, and you've signed the OCA, let me know -- I'll send you an invite.
      • Note that that, when joining the Java EE organization, you are strongly encouraged, but not (yet) required, to:
        • Enable 2FA
        • Make your real name publicly visible
        • Update your avatar
    Thanks for paying attention this long. If you have questions or have trouble getting access to the repos, let me know.

    Regards,

    Will

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     

    OK, thanks. I'll merge that one, possibly onto a different branch. It's pretty close to what I'd propose, but I don't want to check anything onto master just yet.

    On 07/20/2017 05:37 PM, Arjan Tijms wrote:
    On Thu, Jul 20, 2017 at 12:49 pm, Will Hopkins wrote:
    Can you merge them onto a branch in the repository? If so, they'll be carried over when the repository moves.
    I merged the Soteria PR into a new branch ("hashalgorithm"), but I don't have write access for https://github.com/javaee-security-spec/security-api and can't create a new branch there.

    Kind regards,
    Arjan Tijms

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Arjan Tijms
     

    On Thu, Jul 20, 2017 at 12:49 pm, Will Hopkins wrote:
    Can you merge them onto a branch in the repository? If so, they'll be carried over when the repository moves.
    I merged the Soteria PR into a new branch ("hashalgorithm"), but I don't have write access for https://github.com/javaee-security-spec/security-api and can't create a new branch there.

    Kind regards,
    Arjan Tijms


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     

    I think you'll find that you can't push to master, but write access is necessary if you want to update issues or create branches.

    Hopefully we'll all continue to be prudent w.r.t. using PR's.  ;-)


    On 07/20/2017 04:17 PM, Guillermo González de Agüero wrote:
    Thanks for the invite. I've accepted it but now you've granted be push access to the repository! So I can now modify files directly without sending a PR which is not what you were trying to do I guess :)

    I think everybody can make PRs despite not being an organization member. Or are there special restrictions in place here?

    PS: Yes, I already signed the OCA. Arjan pointed me on that directiom at that time.

    Regards,

    Guillermo González de Agüero

    El jue., 20 de julio de 2017 22:09, Will Hopkins <will.hopkins@...> escribió:


    On 07/20/2017 03:58 PM, Guillermo González de Agüero wrote:


    El jue., 20 de julio de 2017 21:55, Will Hopkins <will.hopkins@...> escribió:
    It's best if you are a member of the Java EE organization, because then I can add you to the security "team" in the javaee org, but I can also grant access to outside "collaborators".
    I guess that only applies to EG members? Or contributors can also request to join? If so, how could it be done?
    It applies to anyone who wants to contribute, whether EG member or not. It's best if you're an EG member or official Contributor (which you are), but the real requirement to commit is that you've signed the OCA (I think I saw that you were on the list).

    Note that any github user can clone the repo and submit a pull request (or create an issue, but not update issues).

    See here for legalese about the OCA. I'll have to check how to join the org and get back to you; meanwhile I've invited you as a collaborator for the security-spec repo, and will do the same for the other repos as they migrate.



    Note that I'm planning to manage access a little differently, by allowing write access for all contributors -- so people can create branches, update issues, etc., for all repos -- but protect the master branch, at least for spec and api -- so that I can do change control when needed.

    Note also that I've just been told all contributors going forward must sign the OCA, even folks who are on the EG and therefore presumably have already signed. There's a list of OCA signers at http://www.oracle.com/technetwork/community/oca-486395.html, and if you're not on the list I'm not supposed to allow commits. There are few people who are EG members or listed as Contributors on the JCP.org web site who aren't on the list (including some that have already contributed, but that's apparently not a problem). Sigh.

    Will


    On 07/20/2017 03:20 PM, Rudy De Busscher wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Guillermo González de Agüero
     

    Thanks for the invite. I've accepted it but now you've granted be push access to the repository! So I can now modify files directly without sending a PR which is not what you were trying to do I guess :)

    I think everybody can make PRs despite not being an organization member. Or are there special restrictions in place here?

    PS: Yes, I already signed the OCA. Arjan pointed me on that directiom at that time.

    Regards,

    Guillermo González de Agüero

    El jue., 20 de julio de 2017 22:09, Will Hopkins <will.hopkins@...> escribió:


    On 07/20/2017 03:58 PM, Guillermo González de Agüero wrote:


    El jue., 20 de julio de 2017 21:55, Will Hopkins <will.hopkins@...> escribió:
    It's best if you are a member of the Java EE organization, because then I can add you to the security "team" in the javaee org, but I can also grant access to outside "collaborators".
    I guess that only applies to EG members? Or contributors can also request to join? If so, how could it be done?
    It applies to anyone who wants to contribute, whether EG member or not. It's best if you're an EG member or official Contributor (which you are), but the real requirement to commit is that you've signed the OCA (I think I saw that you were on the list).

    Note that any github user can clone the repo and submit a pull request (or create an issue, but not update issues).

    See here for legalese about the OCA. I'll have to check how to join the org and get back to you; meanwhile I've invited you as a collaborator for the security-spec repo, and will do the same for the other repos as they migrate.



    Note that I'm planning to manage access a little differently, by allowing write access for all contributors -- so people can create branches, update issues, etc., for all repos -- but protect the master branch, at least for spec and api -- so that I can do change control when needed.

    Note also that I've just been told all contributors going forward must sign the OCA, even folks who are on the EG and therefore presumably have already signed. There's a list of OCA signers at http://www.oracle.com/technetwork/community/oca-486395.html, and if you're not on the list I'm not supposed to allow commits. There are few people who are EG members or listed as Contributors on the JCP.org web site who aren't on the list (including some that have already contributed, but that's apparently not a problem). Sigh.

    Will


    On 07/20/2017 03:20 PM, Rudy De Busscher wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     



    On 07/20/2017 03:58 PM, Guillermo González de Agüero wrote:


    El jue., 20 de julio de 2017 21:55, Will Hopkins <will.hopkins@...> escribió:
    It's best if you are a member of the Java EE organization, because then I can add you to the security "team" in the javaee org, but I can also grant access to outside "collaborators".
    I guess that only applies to EG members? Or contributors can also request to join? If so, how could it be done?
    It applies to anyone who wants to contribute, whether EG member or not. It's best if you're an EG member or official Contributor (which you are), but the real requirement to commit is that you've signed the OCA (I think I saw that you were on the list).

    Note that any github user can clone the repo and submit a pull request (or create an issue, but not update issues).

    See here for legalese about the OCA. I'll have to check how to join the org and get back to you; meanwhile I've invited you as a collaborator for the security-spec repo, and will do the same for the other repos as they migrate.


    Note that I'm planning to manage access a little differently, by allowing write access for all contributors -- so people can create branches, update issues, etc., for all repos -- but protect the master branch, at least for spec and api -- so that I can do change control when needed.

    Note also that I've just been told all contributors going forward must sign the OCA, even folks who are on the EG and therefore presumably have already signed. There's a list of OCA signers at http://www.oracle.com/technetwork/community/oca-486395.html, and if you're not on the list I'm not supposed to allow commits. There are few people who are EG members or listed as Contributors on the JCP.org web site who aren't on the list (including some that have already contributed, but that's apparently not a problem). Sigh.

    Will


    On 07/20/2017 03:20 PM, Rudy De Busscher wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Guillermo González de Agüero
     



    El jue., 20 de julio de 2017 21:55, Will Hopkins <will.hopkins@...> escribió:
    It's best if you are a member of the Java EE organization, because then I can add you to the security "team" in the javaee org, but I can also grant access to outside "collaborators".
    I guess that only applies to EG members? Or contributors can also request to join? If so, how could it be done?

    Note that I'm planning to manage access a little differently, by allowing write access for all contributors -- so people can create branches, update issues, etc., for all repos -- but protect the master branch, at least for spec and api -- so that I can do change control when needed.

    Note also that I've just been told all contributors going forward must sign the OCA, even folks who are on the EG and therefore presumably have already signed. There's a list of OCA signers at http://www.oracle.com/technetwork/community/oca-486395.html, and if you're not on the list I'm not supposed to allow commits. There are few people who are EG members or listed as Contributors on the JCP.org web site who aren't on the list (including some that have already contributed, but that's apparently not a problem). Sigh.

    Will


    On 07/20/2017 03:20 PM, Rudy De Busscher wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     

    It's best if you are a member of the Java EE organization, because then I can add you to the security "team" in the javaee org, but I can also grant access to outside "collaborators".

    Note that I'm planning to manage access a little differently, by allowing write access for all contributors -- so people can create branches, update issues, etc., for all repos -- but protect the master branch, at least for spec and api -- so that I can do change control when needed.

    Note also that I've just been told all contributors going forward must sign the OCA, even folks who are on the EG and therefore presumably have already signed. There's a list of OCA signers at http://www.oracle.com/technetwork/community/oca-486395.html, and if you're not on the list I'm not supposed to allow commits. There are few people who are EG members or listed as Contributors on the JCP.org web site who aren't on the list (including some that have already contributed, but that's apparently not a problem). Sigh.

    Will

    On 07/20/2017 03:20 PM, Rudy De Busscher wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     

    Can you merge them onto a branch in the repository? If so, they'll be carried over when the repository moves.

    Note that the security-spec repo is already moved; that one I had to clone into the existing repo at github.com/javaee, the other two will go as a direct transfer.

    Will

    On 07/20/2017 03:29 PM, Arjan Tijms wrote:
    Hi,

    Basically okay, although my 2 outstanding PRs may be an issue.

    Perhaps easiest to accept those both, then migrate, and then later change in that code whatever needs changing still.

    Kind regards,
    Arjan Tijms

    On Thursday, July 20, 2017, Rudy De Busscher <rdebusscher@...> wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@...oups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Arjan Tijms
     

    Hi,

    Basically okay, although my 2 outstanding PRs may be an issue.

    Perhaps easiest to accept those both, then migrate, and then later change in that code whatever needs changing still.

    Kind regards,
    Arjan Tijms


    On Thursday, July 20, 2017, Rudy De Busscher <rdebusscher@...> wrote:
    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@...oups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    



    Re: LDAP Annotation and Database Hashing Proposal

    Arjan Tijms
     

    Hi,

    The adaptability concern is basically the main concern of the entire DataBaseIdentityStore. Indeed, having a query to get the (hashed) password from the caller name and another to get the groups covers maybe 80% of use cases, but certainly not all.

    There are for instance exotic database schemes were you'd need at least 2 seperate queries to get that data.

    For the hash algorithm the same thing holds. We need to specify enough moving parts so we can adapt to *many* existing databases and requirements, but we shouldn't even be dreaming about covering them all.

    Since parameters can contain EL as values as well, it wouldn't be crazy hard really to supply the encoding as a method expression. It's basically a byte[] -> String function.

    In this case though I think encoding is a general enough moving part to warrant its own method in the interface. It can easily be defaulted to e.g. base64 and it can be overridden without exposing the implementation by use of a CDI decorator (or should be after we solve a bug or problem that currently prevents decorating).

    Kind regards,
    Arjan Tijms


    On Thursday, July 20, 2017, Will Hopkins <will.hopkins@...> wrote:


    On 07/20/2017 12:38 PM, Guillermo González de Agüero wrote:


    Similarly, parameters like the salt and iteration count can be defaulted. That way you can have 3 levels:

    1. Specify only the class name; you get defaults for all parameters and it Just Works
    2. Specify the parameters locally to match a specific DB or requirement
    3. (via EL) fetch the parameter values externally

    The most important rule should always be that the developer is in full control, or can be in full control. External overrides should be possible, but never be required. That is -the- big mistake that Java EE made in the past.
    I agree, but I think we're only talking about what the mechanism for override is, and what the trade-off between simplicity and the override mechanism is. In practice, I don't think parameters are going to be very helpful to most developers. They can be used to tweak some simple things, but the simple things won't typically be necessary and the more complex things can't be handled by parameters.
     
    Could you please provide an example of such a setting, please? Just to better understand. Otherwise, we could just wait for your new proposal to see.

    Basically, it's the encoding of the hashed password. Parameters like salt, iterations, hash key size, etc. are all pretty standard. They can be dialed up or dialed down to make the hash stronger or weaker, and I think "stronger vs. weaker" is the level at which most people think about them. I doubt many developers are concerned about specifying precisely a certain number of iterations for some reason, they just want iterations count to be high enough to be secure, without imposing excessive overhead or resource consumption, and security most often wins out vs. resource consumption these days. Most will be happy if they can turn up the volume with a single knob, they don't need bass and treble and balance knobs. Even better: if the default volume is about right, and if the volume automatically goes up when you're driving at higher speeds.

    In contrast, the format of the encoded string is not standard in any way that I'm aware of. There are probably LDAP vendors that do things in a common way, but for any given database user store, either the format has already been decided, because there are existing user accounts, or the developer won't care as long as the default format is reasonable (assuming the DB schema allows enough space for the chosen encoding format.

    I can't think of any good way to standardize parameters to describe how the hashed password is encoded for storage, and that's the hard part, the part that you really have to adapt to. It's not a big deal if you have to use 4000 iterations instead of 2000, but it's a big deal if you can't parse the encoded password. And since the encoding is completely arbitrary and non-standard, that's the real problem, and that's what will likely force people to do their own implementation of HashAlgorithm. That can't be specified as Properties.

    We could probably come up with an interface for encoding/decoding the hashed value, or for describing the encoded value as a string and passing it as a property. But that's a lot to spec out, and we just don't have time for it. It's complicated by the fact that decoding a hash potentially yields all the parameters that were used to generate the hash, so there'd need to be a generalized interface for returning those in a standard way. Plus, in some databases, the encodings used will vary, as legacy hashes are replaced with stronger hashes/different encodings when people change their password.

    It's hard to argue against supplying Properties. It's not difficult to implement, and it might be useful. But I'm trying to keep the interface as simple as possible -- in part to reduce the number of additional TCK tests that need to be written -- and I suspect the Properties will rarely be useful. Some people will want to use them, but for many the defaults will be good enough, and many of those with specific requirements will already be forced to write an implementation in order to deal with encoding issues.

    Will
    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Rudy De Busscher
     

    Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention)

    Rudy

    On 20 July 2017 at 20:39, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    



    Re: LDAP Annotation and Database Hashing Proposal

    Will Hopkins
     



    On 07/20/2017 02:48 PM, Arjan Tijms wrote:
    Hi,

    On Thursday, July 20, 2017, Will Hopkins <will.hopkins@...> wrote:


    On 07/20/2017 10:54 AM, Arjan Tijms wrote:
    On Thu, Jul 20, 2017 at 07:18 am, Will Hopkins wrote:
    First, it seems there's a strong consensus for using IF types instead of names. I still have reservations, but I'm OK moving forward with that.
    Ok, good! :)



    Second, I'd like to reiterate that I don't see what we're doing as providing a mechnism to specify a small set of common, and commonly used, algorithms. Yes, there will be some of that. But equally, there will be a lot of site- and application-specific algorithms.

    This will be like configuring LDAP or Database parameters in many instances. An application doesn't decide up front which LDAP URL it's going to use, or what the bindDN is -- it configures those things at deployment time.
    It depends, many applications actually do decide those things and in those applications it are the developers as well who decide this.

    In the simplest example, if I'm programming a micro application for IoT (on Raspberry pi) I'm the only developer and my application uses only one LDAP URL.

    In a bigger example, when you build and operate your own website (like I did with zeef.com), you only have a select few different LDAP URLs, which are all configured up front in the application, and via a stage parameter (i.e. -Dstage=dev) the right one is chosen. Also there, when you do devops, essentially the developer choose all parameters and set all URLs and what have you.

    This is actually rather common and an area where Java EE has traditionally been lacking, causing a small exodus to other platforms.
    Sure, and we can easily support those use cases. But we should also support the use cases, which do still exist, of enterprise developers, or developers building an app that will be deployed in multiple heterogeneous environments. Why limit ourselves to just one use case?

    Oh, that's definitely not what I'm advocating ;)

    Especially in the beginning of the JSR I strongly advocated to support *both* options, and to support those as transparently as possible. There were some voices back then that seemed to argue for application defined configuration only, of which I'm definitely not a fan either.

     


    Similarly, applications may have to configure a custom hashing algorithm at deployment time, in order to support the existing user store on site, and the configured value won't be PBKDF2 or Argon2, it'll be AcmeCorpCustomHashAlgorithm.
    That option should be taken into account, but as many (web) applications are developed in house and operated by the same company or group that develops it, we have to be careful not to think that deploying the application elsewhere to an unknown site and operated by a separate ops team is the only (or even the most common) use case.
    Sure.

    Similarly, I'm assuming an implementation of the default PBKDF2 would have to implement some standard behaviors by default, but could also support, as value add, encodings and parameter settings not specified by the standard. 
    Indeed, and the generic key/value map enables that.
    To a point, but it specifying parameters implies that those parameters are rigid. Leaving it up the the impl allows a single instance of the impl to be flexible and handle a variety of situations.

    I'm not sure I follow that...
    Probably better to explain using my proposal, if I can get a chance to code it up ...

     



    In the current proposal it's:

    @DatabaseIdentityStoreDefinition(
        dataSourceLookup="${'java:global/MyDS'}", 
        callerQuery="#{'select password from caller where name = ?'}",
        groupsQuery="select group_name from caller_groups where caller_name = ?",
       
        hashAlgorithm = Pbkdf2HashAlgorithmImpl.class,
        hashAlgorithmParameters = {
            "PBKDF2.salt=38687585358",
            "PBKDF2.iterationCount=2048"
        }

    A vendor can very easily and transparently extend that with extra parameters, e.g. :

    @DatabaseIdentityStoreDefinition(
        dataSourceLookup="${'java:global/MyDS'}", 
        callerQuery="#{'select password from caller where name = ?'}",
        groupsQuery="select group_name from caller_groups where caller_name = ?",
        
        hashAlgorithm = Pbkdf2HashAlgorithmImpl.class,
        hashAlgorithmParameters = {
            "PBKDF2.salt=38687585358", 
            "PBKDF2.iterationCount=2048"
            "com.oracle.webLogic.middleware.encryption.d2of2.tMinS=5"
        }

    Where the extra parameter is used to set the minimal time the algorithm should take before returning.


    but I'd argue that you don't want developers specifying that level of detail. For the few cases where they really want/need to, they can write a HashAlgorithm instance to do what they want.
    As a developer myself and looking back at what my previous teams did, I'm 100% convinced developers do want that ;)
    Perhaps, but I'm not sure that always leads to better security. If we make it so they don't have to care, and they know they'll get good security, they won't worry about parameters. 

    I'm not entirely convinced about that. The issue is that this is largely what was said about security (mostly the proprietary identity store) being defined on the server, since it would, indeed, lead to better security.

    However, as we know now, if developers can't configure every attribute there is, they simply avoid the offering altogether, which leads generally to far less secure applications.

    If we don't give developers full and total control to all options here many will just code up their own database identity store, which I think is not quite what we want.
    Agree, but allowing the developer to provide their own HashAlgorithm implementation gives them complete control. By way of contrast, Properties -- though admittedly a simple and harmless thing to support -- gives the illusion of configurability without really providing much meaningful flexibility. There are lots of config/customization cases that Properties can't easily address.

    Given the time frame we have -- and the reality that every extra "config option" we provide generates new TCK test cases that have to be written -- I'm leaning toward giving developers a choice between, "simple, with secure defaults", and "full control (by writing an impl)". Adding Properties as a third, in-between option, means more work to specify, implement and test, and I'm not sure it helps that many people.

    For more on why I think Properties won't help in many cases, see my discussion of encoding formats in my last email.



    Your salt specification above, for example, is an anti-pattern. (Each password should have a different salt -- salt size is the value I'd argue we should support, if anything. If you want an algorithm that uses the same hash for every password, that's something you should have to write yourself.)

    The above is just an example of course; the exact same parameter could either be defaulted, use a constant hash, or use a method reference of some kind.

    What the default would be and what the expression exactly looks like was left open for now.

    The key here is that developers are not required to set parameters, but can do so if needed.
    Yeah. I'm generally supportive, but trying to keep things simple and limit config options here. The ability to supply their own implementation does provide complete control for those who really want it, and a default impl can satisfy most everyone else's needs, I think. (You can judge for yourself when I post my proposal.)


    Kind regards,
    Arjan Tijms
     

    Leaving the behavior up to the implementation will allow platforms and deployment environments to provide algorithm implementations that are flexible and support specific -- and possibly variable -- requirements, without exposing that complexity to the application. Part of my thinking with this was to completely externalize all those details, with the app knowing nothing but the name of an implementation (or, now, the classname).
    This can still be done, since the parameters can be EL enabled and then fetch the config externally.

    Similarly, parameters like the salt and iteration count can be defaulted. That way you can have 3 levels:

    1. Specify only the class name; you get defaults for all parameters and it Just Works
    2. Specify the parameters locally to match a specific DB or requirement
    3. (via EL) fetch the parameter values externally

    The most important rule should always be that the developer is in full control, or can be in full control. External overrides should be possible, but never be required. That is -the- big mistake that Java EE made in the past.
    I agree, but I think we're only talking about what the mechanism for override is, and what the trade-off between simplicity and the override mechanism is. In practice, I don't think parameters are going to be very helpful to most developers. They can be used to tweak some simple things, but the simple things won't typically be necessary and the more complex things can't be handled by parameters.



    P.S., I'd like to take a shot at implementing the default HashAlgorithm class (and API code).
    You mean PBKDF2? That has already been implemented:

    @ApplicationScoped
    public class Pbkdf2HashAlgorithmImpl implements Pbkdf2HashAlgorithm {
     
        @Override
        public boolean verifyHash(char[] password, String hashedPassword, Map<String, String> parameters) {
            return 
                pbkdf2(
                    password, 
                    parameters.get("PBKDF2.salt").getBytes(),
                    Integer.valueOf(parameters.get("PBKDF2.iterationCount"))
                )
                .equals(hashedPassword);
        }
        
        private String pbkdf2(char[] password, byte[] salt, int iterationCount) {
            try {
                return 
                    Base64.getEncoder()
                          .encodeToString(
                              SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1")
                                              .generateSecret(
                                                 new PBEKeySpec(password, salt, iterationCount, 64 * 8))
                                              .getEncoded());
                
            } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {
                throw new IllegalStateException(e);
            }
        }
        
    }

    See:

    https://github.com/arjantijms/soteria/blob/expression-language/impl/src/main/java/org/glassfish/soteria/identitystores/hash/Pbkdf2HashAlgorithmImpl.java

    The API is in javax.security.enterprise.identitystore.Pbkdf2HashAlgorithm combined with a description of the parameters it accepts ("BKDF2.salt" and "PBKDF2.iterationCount"

    Kind regards,
    Arjan Tijms

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


     


     

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    Re: WARNING! PLEASE READ! (Was: Fwd: Re: [javaee-security-spec] Moving to Java EE Github?)

    Will Hopkins
     

    Thanks, Guillermo.

    On 07/20/2017 02:42 PM, Guillermo González de Agüero wrote:
    Ok from me

    On Thu, Jul 20, 2017 at 8:39 PM, Will Hopkins <will.hopkins@...> wrote:
    So is everybody OK with me moving repos today?

    SPEAK NOW OR FOREVER HOLD YOUR PEACE!


    On 07/20/2017 10:38 AM, Will Hopkins wrote:
    I thought I sent this out yesterday, but forgot to copy the list -- just as well that I wasn't able to complete the migration last night, although I did get started on the security-spec repo.

    Please note the part about issue management -- I think it will be helpful to use issues to track what we're working on, to avoid duplicate effort or working at cross purposes -- for now, lets use soteria repo issues to track who's working on tasks.

    Will

    On 07/19/2017 12:49 PM, Will Hopkins wrote:
    MOVING THE REPOS TODAY!

    Unless there are objections, I plan to migrate the security-spec, security-api, and soteria repos to the Java EE github organization today. Since most of you are in Europe, I'll do it during the evening my time, which will be very late at night CET.

    Before doing so, I'll disable access for everyone, to avoid interrupting a commit or an issue update. Once everything is successfully migrated, I'll re-enable access on the Java EE side.

    ISSUE MANAGEMENT:

    On a slightly different topic, I plan to triage the outstanding Issues for both security-spec (@javaee org) and soteria, and use them to manage the remaining work. Please plan to track work you're doing with github issues. I'll send a more detailed email on this topic soon.

    Regards,

    Will


    -------- Forwarded Message --------
    Subject: Re: [javaee-security-spec] Moving to Java EE Github?
    Date: Tue, 18 Jul 2017 22:13:12 -0400
    From: Will Hopkins <will.hopkins@...>
    To: javaee-security-spec@javaee.groups.io


    I think I'm about ready to migrate the repos to the javaee organization.

    If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

    The plan is to migrate as follows:
    • security-spec -> javaee/security-spec
      • issues are already there (migrated from java.net)
      • migrate the source only, using git clone
      • recreate releases based on migrated tags at the destination
      • will lose pull-request history, but should preserve everything else we need.
    git clone --bare $GITHUB_URL_OLD_REPO
    cd <repo-name>.git
    git push --mirror $GITHUB_URL_NEW_REPO
    • security-api -> javaee/security-api
      • use github "transfer" function to migrate entire repo
    • soteria -> javaee/security-ri-soteria
      • use github "transfer function to migrate  entire repo
      • rename repo when transfer completes

    I'll make a full (bare) clone of each repo before transferring it.

    Seem like a reasonable plan?

    Will




    On 07/11/2017 02:21 PM, Werner Keil wrote:
    Ok, let us know, if you need any help by those who have the necessary rights.

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    


    -- 
    Will Hopkins | WebLogic Security Architect | +1.781.442.0310
    Oracle Application Development
    35 Network Drive, Burlington, MA 01803
    

    261 - 280 of 736