Security discussion

[Arjan Tijms]

Hi,

For typical web service/api/restfull backends which seems to be what the micro profile is targeting, one thing that I almost always see being needed is security. Endpoints like e.g. http://example.com/api/me obviously need authentication.

Indeed, an explanation on how to obtain some kind of token for usage in (restful) APIs is often the first thing documentation of such API discusses.

Yet, in Java EE there's no default authentication mechanism available that's really suitable for this, and there sure isn't a simple / standard way to set up the matching identity store.

The Java EE Security API (JSR 375) is however looking at exactly this. A somewhat older example (predating JSR 375) suitable for securing JAX-RS based endpoints looks like this: http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html

Although it's by far not ready yet, I think the Java EE Security API would be a good match for the Micro Profile.

Thoughts?

[Ondrej Mihályi]

Hi Arjan,

A simple security API is a long-awaited addition to Java EE. Although nobody really thinks about security when developing an app, everyone needs to add security after all - and everyone wants to have a simple API to do it so that they don't need to think about it much.

Although Micro Profile should be a small set of APIs to start with, I really strongly suggest to include the new security JSR, provided that it is really simple and thin abstraction.  It should provide only common interfaces/annotations and glue between the runtime (app server) and an implementation in the application (which can be anything, from an OAuth library to a complete solution like Apache Shiro). For a Micro profile, I believe there should be no implementation of the API and application developers should be completely free to choose to bundle any implementation within their application.

With Micro profile, I would focus on having small subset of really important and frequently used specifications, however, it also makes sense to include the specifications that are not so often used but are small and efficient (no complex API, concise specification documents and small implementation footprint in disku and memory usage).

Ondrej

Dňa pondelok, 27. júna 2016 20:48:54 UTC+2 Arjan Tijms napísal(-a):

[Arjan Tijms]

On Monday, June 27, 2016 at 9:36:58 PM UTC+2, Ondrej Mihályi wrote:

A simple security API is a long-awaited addition to Java EE. Although nobody really thinks about security when developing an app, everyone needs to add security after all - and everyone wants to have a simple API to do it so that they don't need to think about it much.

Indeed. To actually make an application secured, e.g. guarding access to restricted resources in a correct way is not rarely an afterthought. But, authentication it self comes up pretty quickly in most every restful web services design, since you simply need to know which user is using the web service for things like /me. 

 

Although Micro Profile should be a small set of APIs to start with, I really strongly suggest to include the new security JSR, provided that it is really simple and thin abstraction.

This is indeed the idea. For example, this gives an example of fully defining security for a Servlet in the most basic way: 

https://github.com/javaee-security-spec/soteria/blob/master/test/app-mem-basic/src/main/java/test/Servlet.java#L21

There's nothing needed for configuration beyond that. Not in the application and not in the server. One annotation to say that the authentication mechanism is basic, and another annotation to define an embedded identity store with 3 hardcoded users (obviously, just for testing).

 

For a Micro profile, I believe there should be no implementation of the API and application developers should be completely free to choose to bundle any implementation within their application.

I don't quite understand this part. If the burden for finding and bundling compatible implementations is placed on the user, then what distinguishes the Micro Profile from say Tomcat or Jetty, where users are also completely free to bundle any JAX-RS, CDI, Bean Validation and security implementation they wish?

Isn't the idea of a profile that it provides a small but focussed set of ready to use functionality?

Kind regards,

Arjan Tijms

[Ondrej Mihályi]

I'll reply below:

 

For a Micro profile, I believe there should be no implementation of the API and application developers should be completely free to choose to bundle any implementation within their application.

I don't quite understand this part. If the burden for finding and bundling compatible implementations is placed on the user, then what distinguishes the Micro Profile from say Tomcat or Jetty, where users are also completely free to bundle any JAX-RS, CDI, Bean Validation and security implementation they wish?

Isn't the idea of a profile that it provides a small but focussed set of ready to use functionality?

What I meant is that providing basic features for a Micro profile is OK, as it is a negligible burden if not used. But providing more complicated mechanisms should be pluggable (like complex role to user mapping, support for many types of reals, such as LDAP, authentication by OAuth). The advantage of Micro profile would still be providing a common pluggable mechanism for extensions, so that e.g. authentication via facebook could be provided by an external library, but without any integration fuss, as the ibrary itself would be likely to provide integration with a standardized mechanism. And even if not, it should be easy to write custom glue code for and it and then continue using standard API for authorization.

The point to have support in the container is to separate business logic from the implementation of the security, even if both are provided by the application itself. The advantage is that the application can later support more and more realms without the need to change the code of the business logic.

Cheers,
Ondrej Mihályi

[Arjan Tijms]

Hi,

On Tuesday, June 28, 2016 at 12:28:10 AM UTC+2, Ondrej Mihályi wrote:

What I meant is that providing basic features for a Micro profile is OK, as it is a negligible burden if not used. But providing more complicated mechanisms should be pluggable (like complex role to user mapping, support for many types of reals, such as LDAP, authentication by OAuth).

Just a small terminology thing, in JSR 375 (and hopefully eventually the whole of EE) the term for the "user database" is identity store ;) "realm" was never an official EE term either, but just one that GlassFish used (and some others, but often with conflicting meanings).

The idea is that JSR 375 will standardise on a few types of identity stores, but not an exhaustive list, of course. Just like JSF ships with a few basic components and leaves more advanced ones to say PrimeFaces.

That said, LDAP is really well understood and targeted as one if the identity stores JSR 375 will ship by default. But it's a small class that just sits there if not used. See https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/identitystores/LDapIdentityStore.java

As of now there are only 3 of those standard identity stores. E.g. the one backing the annotation showed in the example above is this one: 

https://github.com/javaee-security-spec/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/identitystores/EmbeddedIdentityStore.java

 

The advantage of Micro profile would still be providing a common pluggable mechanism for extensions, so that e.g. authentication via facebook could be provided by an external library, but without any integration fuss, as the ibrary itself would be likely to provide integration with a standardized mechanism.

If anything, that's goal number one, and one of the things we worked on first.

To provide a new (custom) identity store, users only have to put an implementation of this on the class path. There's zero config needed:

public interface IdentityStore {

    CredentialValidationResult validate(Credential credential);

}

There's an example of that here:

https://github.com/javaee-security-spec/soteria/blob/master/test/app-custom/src/main/java/org/glassfish/soteria/test/TestIdentityStore.java

To provide a custom authentication mechanism a similar single interface (often) single method with zero config has to be provided. There are a few open questions, such as what if we want to make an implementation provided by a library available with some config from the application, but the above does show the general direction.

 

The point to have support in the container is to separate business logic from the implementation of the security, even if both are provided by the application itself.

Indeed, that's exactly what's happening. The two main security artefacts can be provided by either the application or the container (or one by the app, one by the container), and you can transparently switch between those options without any business code being aware. That business code only uses the @RolesAllowed and associated constructs to test permissions and don't know (and don't care) how the authenticated identity was established.

Kind regards,

Arjan Tijms

[Ehsan Zaery Moghaddam]

Hi Guys

I'm agree with Arjan. As an application developer, I definitely need to have a sort of authentication that at least supports some well known protocols/stores for authentication (LDAP, In Memory for test and DB). Considering efforts made on JSR-375 and its RI, Soteria, I think it would be very easy for me to start developing my microservice using a simple in memory identity store and whenever needed, plug another or even a custom store to be used in production/integration/staging environment.

IMHO if you're trying to create a sort of "Profile", having something that (at least) is going to be part of the Java EE in future (near or far) is better than using a third party library. By using a library, we'll have something that is more like a framework than a profile.

Regards

Ehsan

[Tobias F]

Hi!

If the MicroProfile targets to support a micorservices oriented architecture I'd guess we'd like to have a token based authentication mechanism around. Somehting along the lines of Kerberos or SPNEGO. I am not really uptodate what the state of the art in the area is right now. Is that covered by OAUTH? Or SAML? 

Can someone shed some light onto this area please?

Thanks,

Tobias

[alasdair....@gmail.com]

I think OpenID Connect, OAUTH, OpenID and SAML Web SSO are all playing in this space. From what I see some variant of the first 3 is very popular on the web. JWT is popular. SAML Web SSO is used by a lot of enterprises. Not sure I have a view on which subset should be in MicroProfile, but I suspect it wont be a single one.

[Arjan Tijms]

On Wednesday, June 29, 2016 at 4:05:54 PM UTC+2, alasdair....@gmail.com wrote:

I think OpenID Connect, OAUTH, OpenID and SAML Web SSO are all playing in this space. From what I see some variant of the first 3 is very popular on the web. JWT is popular. SAML Web SSO is used by a lot of enterprises. Not sure I have a view on which subset should be in MicroProfile, but I suspect it wont be a single one.

There's indeed almost never a single fit.

Purely from an application developer point of view (ignoring my role in the JSR 375 EG), we always use access tokens that the API / web-service user first has to obtain.  It's then used as follows:

curl -vs -H "Authorization: ExampleComLogin auth=7bb04e-4490-0000-x99x-44019faa8867-ffaa99" https://example.com/api/me

See e.g. https://zeef.com/features/api

Naturally, using SSL is of the utter most importance here (you can enforce this a little by immediately expiring a token when it comes in via http instead of https) 

Kind regards,

Arjan Tijms

[Tom Anderson]

I've mostly built microservices to be used within an organisation, rather than facing the internet. There, the first, and often last, authentication mechanism we implement is HTTP basic authentication, checking the username and password against a single user identity supplied to the application using environment variables. That is, if the service's environment contains:

SERVICE_USERNAME=nuclear_reactor_admin

SERVICE_PASSWORD=atoms4fun

Then those are the username and password a client have to present. Sometimes we bundle up the username and password into some JSON in a single environment variable, but there's still only one account. It's insanely simple, but it's good enough for many situations. Will JSR 375 be able to support this?

tom

[Tobias Frech]

Hi Arjan,

so you are replacing user/credentials with a token that needs to be managed separately.

I was more thinking about a front-end system authenticating the user against an identity provider (AD, LDAP). That front-end system is going to use various microservices which again need the user to be authenticated and authorized. Instead of the front-end server sending the credentials to all the back-end services and each back-end service needing to reauthenticate the user against the identity store I'd like to have a more kerberos like setup.

The front-end server obtains a ticket for the user and sends this ticket along with all requests to the back-end servers. Through the ticket the user is then authenticated and if it also contains the roles may also be authorized. The ticket itself cannot be modified and can be trusted by the back-end service since it is encrypted with a preshared secret.

I have seen larger customers trying to move too such an architecture and I am expecting more of this to be requested as monolithic systems are broken up into smaller services.

Given the reactions here so far this may be a bit far ahead and something to consider in a later iteration.

Cheers,

Tobias

[arjan tijms]

On Wed, Jun 29, 2016 at 5:24 PM, Tom Anderson <toand...@pivotal.io> wrote:

Then those are the username and password a client have to present. Sometimes we bundle up the username and password into some JSON in a single environment variable, but there's still only one account. It's insanely simple, but it's good enough for many situations. Will JSR 375 be able to support this?

Yes, that should absolutely be supported.

An HTTP BASIC authentication mechanism is one of the default shipped mechanisms (still need to see if we can somehow align that with Servlet's one). 

An identity store that reads the environment variables SERVICE_USERNAME and SERVICE_PASSWORD would be absolutely trivial to implement. Basically this:

@RequestScoped

public class TestIdentityStore implements IdentityStore {

    

    public CredentialValidationResult validate(UsernamePasswordCredential usernamePasswordCredential) {

        

        if (usernamePasswordCredential.getCaller().equals(getenv("SERVICE_USERNAME")) && 

            usernamePasswordCredential.getPassword().compareTo(getenv("SERVICE_PASSWORD"))) {

            

            return new CredentialValidationResult(

                VALID, 

                new CallerPrincipal(getenv("SERVICE_USERNAME")), // or any other name

                asList("foo", "bar") // or none or whatever other groups

            );

        }

        

        return INVALID_RESULT;

    }

    

}

You'd only have to have this class in your application. The HTTP BASIC authentication mechanism will then automatically find it and use it.

Kind regards,

Arjan Tijms

 

tom

On Monday, June 27, 2016 at 7:48:54 PM UTC+1, Arjan Tijms wrote:

Hi,

For typical web service/api/restfull backends which seems to be what the micro profile is targeting, one thing that I almost always see being needed is security. Endpoints like e.g. http://example.com/api/me obviously need authentication.

Indeed, an explanation on how to obtain some kind of token for usage in (restful) APIs is often the first thing documentation of such API discusses.

Yet, in Java EE there's no default authentication mechanism available that's really suitable for this, and there sure isn't a simple / standard way to set up the matching identity store.

The Java EE Security API (JSR 375) is however looking at exactly this. A somewhat older example (predating JSR 375) suitable for securing JAX-RS based endpoints looks like this: http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html

Although it's by far not ready yet, I think the Java EE Security API would be a good match for the Micro Profile.

Thoughts?

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/vKbIbjSiGZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ee6f4443-4546-44a4-b896-a95826e17dcd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[arjan tijms]

Hi,

On Wed, Jun 29, 2016 at 6:08 PM, Tobias Frech <tobia...@gmail.com> wrote:

so you are replacing user/credentials with a token that needs to be managed separately.

In that example, indeed. It's really easy to set up. But it's of course not the only way.

 

I was more thinking about a front-end system authenticating the user against an identity provider (AD, LDAP).

That front-end system is going to use various microservices which again need the user to be authenticated and authorized. Instead of the front-end server sending the credentials to all the back-end services and each back-end service needing to reauthenticate the user against the identity store I'd like to have a more kerberos like setup.

The front-end server obtains a ticket for the user and sends this ticket along with all requests to the back-end servers. Through the ticket the user is then authenticated and if it also contains the roles may also be authorized. The ticket itself cannot be modified and can be trusted by the back-end service since it is encrypted with a preshared secret.

Yes, that's a viable system as well. It's a bit how JWT and identity/trust propagation works. JSR 375 certainly does not stand in the way of that, as the authentication mechanisms and identity stores can be freely replaced with whatever the user wants. I'd say that the back-end services would then have an identity store that just checks if the ticket is valid and takes the user/caller name and groups/roles from it, without having to go all the way to LDAP or anything else.

In case of the micro profile the bigger question is perhaps if such authentication mechanisms and identity stores have to be provided by the profile.

Kind regards,

Arjan Tijms

 

--

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/vKbIbjSiGZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/9d73ccfe-c10f-45c7-a0c9-65efdeccd972%40googlegroups.com.

[Hendrik Ebbers]

I think the profile should provide a small API to add security metadata (annotations) to endpoints. The way how it is internally secured (JWT, Basic auth, ...) can be provided by any additional API that is not part of the profile (but maybe of the underlying container). 

[Antonio Goncalves]

+1 for JWT

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/200150c6-bd82-4f11-bc5a-e867f4eb809d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Arjan Tijms]

On Monday, July 4, 2016 at 10:10:06 AM UTC+2, Antonio Goncalves wrote:

+1 for JWT

JWT is absolutely something JSR 375 could look at. There's already a volunteer looking at it, but as time permits I'll look at creating a JIRA issue for this and starting a discussion about it.

In the meantime, if you (or anyone else) has more concrete input for the JWT story, don't hesitate to contribute to the discussion here already.

Thanks! 

[Werner Keil]

That's exactly why I found it odd Antonio suggested adding all sorts of technology buzzwords like OAuth or JWT. Too much detail...

Neither of them despite based on some RFCs are truly interoperable. There will always be differences between providers, so leaving that to the container sounds best.

While JSR 351 went away, there are so many other standards like SAML one might use but only in certain areas. 

As JSR 375 looks right now, it also should be seen in a more modular way. And maybe things have to be de-scoped or at least offered only to a certain profile (of Java EE 8 and above;-)

Werner

[arjan tijms]

Hi,

On Sunday, July 10, 2016, Werner Keil <werne...@gmail.com> wrote:

That's exactly why I found it odd Antonio suggested adding all sorts of technology buzzwords like OAuth or JWT. Too much detail...

Neither of them despite based on some RFCs are truly interoperable. There will always be differences between providers, 

True, but you can get quite far with a basic and universal Oauth implementation. Some key configuration details have to be left to the application and/or third party lib, so it works with eg Google or Facebook Oauth.

See: https://github.com/omnifaces/soteria-google-oauth-client

 

so leaving that to the container sounds best.

While JSR 351 went away, there are so many other standards like SAML one might use but only in certain areas. 

As JSR 375 looks right now, it also should be seen in a more modular way. And maybe things have to be de-scoped or at least offered only to a certain profile (of Java EE 8 and above;-)

Currently Soteria works on existing Java EE 7 servers. There's no dependency on any EE 8 API yet. It should theoretically work on Tomcat + CDI lib added (haven't tested yet, but will soon).

Did you already had any specific modules / splitting in mind for JSR 375? 

At the moment it's still rather small. There's the authentication mechanism and identity store interfaces, both are quite small, and a few implementations of each.

Kind regards,

Arjan Tijms

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1fd89c48-4ba1-4111-83b0-1c7aaf796e1a%40googlegroups.com.

[Werner Keil]

Am Sonntag, 10. Juli 2016 18:15:34 UTC+2 schrieb Arjan Tijms:

Hi,

On Sunday, July 10, 2016, Werner Keil <werne...@gmail.com> wrote:

That's exactly why I found it odd Antonio suggested adding all sorts of technology buzzwords like OAuth or JWT. Too much detail...

Neither of them despite based on some RFCs are truly interoperable. There will always be differences between providers, 

True, but you can get quite far with a basic and universal Oauth implementation. Some key configuration details have to be left to the application and/or third party lib, so it works with eg Google or Facebook Oauth.

See: https://github.com/omnifaces/soteria-google-oauth-client

 

so leaving that to the container sounds best.

While JSR 351 went away, there are so many other standards like SAML one might use but only in certain areas. 

As JSR 375 looks right now, it also should be seen in a more modular way. And maybe things have to be de-scoped or at least offered only to a certain profile (of Java EE 8 and above;-)

Currently Soteria works on existing Java EE 7 servers. There's no dependency on any EE 8 API yet. It should theoretically work on Tomcat + CDI lib added (haven't tested yet, but will soon).

Since JSR 375 is a rather new JSR it does not have dependencies other than existing "java.security" or "javax.security" and others like CDI, so it would not depend on Java EE 8, but as of now, the only Spec Lead is Oracle, so it won't progress either unless this problem can be solved. If so, then JSR 375 could progress independent of the others or when a "Umbrella" JSR is supposed to finish. Although the detail page states "This specification is targeted for Java EE 8 or higher platforms." which means it would not expect to target Java EE or SE 7 any more, unless JSR 375 and Soteria ended up using Java SE 8 features like Lambdas, they could easily be used with Java EE 7, too ;-)

I guess we'd have to wait for that JavaOne decision making, otherwise like most other (non-withdrawn) EE JSRs 375 will face another Renewal Ballot in November.

Kind Regards,
Werner
 

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

[Michael Remijan]

What I'm most curious about is if Soteria will provide a single-sign-on proxy capability, take care of all of the user login and redirection back to your application?  An easy to implement way too do to this and integrate with application is needed.  I really want to get security out of my applications.

[Werner Keil]

I know, JSR 351 was working on that, it already had some use cases for SSO using popular services like Facebook or Google, but it's been stopped now. So no further development (and eventually the code repo will also go away)

SSO is rather tricky and unfortunately so called standards like OAuth are only partially specified or most providers "extend" it with their own proprietary attributes, so it's hard to do. Plus some like Facebook won't even work until you point them to a "public corporate app". Been there with Agorava, at the moment Facebook is among the worst for Java EE. Ironically standalone Java SE like apps (including Android) have far fewer problems to connect to and use the average OAuth service.

Werner

[Michael Remijan]

I agree that public SSO is tough.  It's nice some sites I can use my LinkedIn or Yahoo! account to login but in my day to day it's not often I come across it.  Internally within an organization, SSO is much more important and I think a lot easier because I highly doubt organizations want their employees to use Facebook to authenticate to their internal applications.  There is a fairly small number of identity stores most organizations use (database, ldap, active directory).  Concentrating on these and providing easy configuration to integrate with existing internal EE applications would satisfy a large percentage of the need.  This is even more true today as companies try to go Microservice...before I might have had a dozen applications to deal with, now I got 100 Microservices I need to figure out how to pass credentials to and build a Principal.

[Werner Keil]

To be taken seriously by the likes of Twitter (except a quota it's Oauth connector works relatively well in Agorava;-) Facebook or LinkedIn/Microsoft for most of them it would require a public test bed running on github.io, microservice.io or wherever, as long as it's a place where a Soteria "sandbox" can be seen by those providers and they can make up their mind if they approve to use it or not.

At least that's the case with Facebook. And many other services and API vendors who have no problem authenticating block the average "localhost" demo due to spam filters or similar. There also it needed a solid, trusted test bed for Soteria or any comparable OAuth service to even demonstrate its capabilities.

[Werner Keil]

Btw. I guess the group's name could be a bit wrong, but especially after JSR 364 went live, there is no reason why "contributors" should not also share their thoughts, so 70 or 90% of what was discussed in this thread actually better belonged here;-)
https://groups.google.com/forum/#!forum/jsr375-experts

Werner

[Werner Keil]

The JSR 375 Experts list may likely be restricted to EG Members, so I created
https://groups.google.com/forum/#!forum/jsr375-contributors

Please feel free to join, it's open to everyone (the list even to non JCP members;-)
I added a few other known (and active) EG members plus Alex. Arjan is also manager but from how I set it up it should be self-registering. Managers can and should handle spam if we get any.

Looking forward to extended Security discussions there, here IMHO there should not be implementation details about JSR 375 or other JSRs mainly use cases or integration issues;-)

Werner

[Arjan Tijms]

Hi,

On Monday, July 11, 2016 at 4:30:43 PM UTC+2, Michael Remijan wrote:

What I'm most curious about is if Soteria will provide a single-sign-on proxy capability, take care of all of the user login and redirection back to your application?

This fully featured type of SSO, not (yet) specifically. Although several building blocks are there. There's the somewhat related "remember me" functionality, where a regular login is exchanged for a token, and henceforth the token is used to authenticate against. See http://arjan-tijms.omnifaces.org/p/whats-new-in-java-ee-security-api-10.html#33

There's also an OAuth2 client connector available, be it outside the RI for now as it has a dependency that is not compatible with the GPL. See https://github.com/omnifaces/soteria-google-oauth-client

For an API spec such as JSR 375, we woud not really be able to ship an actual ready to use application, but we could provide most of the infrastructure necessary. This would include the OAuth2 client authentication mechanism and matching identity store, a server OAuth2 implementation, and actually the possibility to let a user choose between multiple authentication mechanisms (so on the "login server" you can choose between e.g. login with email, login with Facebook etc).

It's a topic close to my heart as I've recently implemented something just like this together with my friend and co-worker Jan Beernink, albeit in a company setting and outside the JSR 375 work.

Kind regards,

Arjan Tijms

[Arjan Tijms]

Hi,

On Monday, July 11, 2016 at 6:11:18 PM UTC+2, Werner Keil wrote:

The JSR 375 Experts list may likely be restricted to EG Members, so I created
https://groups.google.com/forum/#!forum/jsr375-contributors

There's actually a user's list ;) This is basically open to everyone (you only need to register for java.net and subscribe); https://java.net/projects/javaee-security-spec/lists/users/archive

I'll take a look at the Google group too, thanks Werner!

Kind regards,

Arjan Tijms

[Werner Keil]

Yes, but it's on java.net which as we know won't be around much longer. "Users" or "Contributors" can be seen in a similar way, ideally for now we welcome contributions. And everyone should be able to join, even after java.net was either shut down or turned read-only.

Cheers,
Werner