Date   

Re: ACTION REQUIRED: JSR-375 Expert Group

Will Hopkins
 

Bill,

So the category of "trivial" changes you describe corresponds to the description of errata in your JCP Processes writeup?

That being the case, what JCP process applies to errata? I didn't see a reference to it on the process or spec lead pages (though I didn't do a deep dive). Is errata something I can just do? Does it get vetted or approved somehow? How do I document it (i.e., with a change list or something)?

Lastly, would acknowledgements fall into the category of errata? I'd like to acknowledge Alex Kosowski's role as spec lead getting the JSR off the ground.

Will

On 08/04/2017 04:26 PM, Bill Shannon wrote:
Arjan Tijms wrote on 08/ 2/17 02:05 PM:
As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.
As Will explained, the materials submitted to the JCP aren't exactly the final versions since at least things like the license and the version number will change, and we have to allow for the possibility that the vote will fail and larger changes will be required.

We use our best engineering judgment when deciding whether to fix other "trivial" bugs such as typos, formatting, or line endings.

That said, many of the comments in this thread go beyond trivial obvious fixes, and would require at least a JCP errata MR to update the document without changing the spec requirements or version.

See my definition of errata in my JCP Processes writeup.


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


Re: JSR-375 Session at JavaOne

Werner Keil
 

And btw. there is at least one or the other Java EE 8 proposal to JVM-Con in late November, but nothing on JSR 375. I can't say how many slots the "Security" topic would get, but so far there's been only one proposal for the "Java Security" keyword. 

Especially those who are not far from Cologne, give it a try,

Werner


Re: JSR-375 Session at JavaOne

Werner Keil
 

No worries. As it looks like one or the other session (like this one;-) does flock in being approved a little later, it could be one on JSON (JSON-P 1.1 and JSON-B 1.0 combined, like Dimitry and I did in Sofia) also gets approved. And I told Dmitry, if he met a similar fate I could also help out (like I did for JSR 374 last year)
At least for JNoSQL Otavio had me as co-speaker, so I was already proposed for up to 3 sessions, should at least one get a late approval, I may have something to do. And similar to Ivar, I am also supposed to be there for the EC meeting.

Werner


Re: JSR-375 Session at JavaOne

Will Hopkins
 

Hi Werner,

Yes, it's been approved.

Thanks for the offer, but I'd actually like to keep this as a single-speaker talk -- it wasn't pitched as a panel or BOF, and I believe the session is only 45 minutes.

Will

On 08/10/2017 11:01 AM, Werner Keil wrote:
All,

Thanks for letting us know. Has the session as such been approved?

Like Ivar I do not necessarily need to have a talk, but since I gave several JSR-375 presentations at CodeMotion, Java2Days or the upcoming JCON in Germany, and having done a joint talk with Ivar at DWX lately, I'd be happy to participate in that as well.

Werner

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


Re: JSR-375 Session at JavaOne

Werner Keil
 

All,

Thanks for letting us know. Has the session as such been approved?

Like Ivar I do not necessarily need to have a talk, but since I gave several JSR-375 presentations at CodeMotion, Java2Days or the upcoming JCON in Germany, and having done a joint talk with Ivar at DWX lately, I'd be happy to participate in that as well.

Werner


JSR-375 Session at JavaOne

Will Hopkins
 

All:

Unfortunately, I won't be able to attend JavaOne in October, so can't present the session that I'd planned.

Fortunately, Ivar Grimstad will be attending, and has agreed to present the session in my place.

I'm disappointed that I can't attend, but I know Ivar will represent JSR-375 very capably. Thanks, Ivar!

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


Re: Need to resolve outstanding issues with LdapIdentityStore

Will Hopkins
 

Thanks, Guillermo. Comments inline.

On 08/10/2017 02:11 AM, Guillermo González de Agüero wrote:
Hi,

El mar., 8 ago. 2017 a las 11:37, Will Hopkins (<will.hopkins@...>) escribió:
I've been looking at the pile of bugs currently filed against the default LdapIdentityStore in Soteria, and have noticed a couple broad themes. I'd appreciate some feedback on these ASAP, as we need to decide on a consistent approach so we don't end up with wildly inconsistent behavior for different scenarios.

I'm compiling a list in issue #165, but want to call your attention to a couple items in particular:
  • Returning NOT_VALIDATED vs. throwing an exception from validate():
My understanding to date has been that NOT_VALIDATED has a very specific meaning -- i.e., the identity store didn't attempt to validate the credential, because it doesn't handle that credential type. Errors -- network errors, config errors, etc. -- always result in a runtime exception being thrown.

This is reasonable if we expect errors to be rare, but the behavior isn't documented -- since there are no checked Exceptions, and we didn't add an explicit javadoc reference to runtime exceptions -- and it seems to happen pretty frequently since config problems don't typically fail deployment. This is the source of a lot of the outstanding bugs.

On balance, I'm leaning toward returning NOT_VALIDATED rather than throwing exceptions, and some fixes have already been made that catch exceptions rather than letting them propagate out of validate(). That said, I don't have really strong feelings either way -- we just need to pick one way or the other and handle errors consistently.
I prefer to throw exceptions at this moment so we can decide on a future version wether it's preferrable to create a VALIDATION_ERROR result, or if deployment validation is achievable and validation errors become rare.
Agree, and although the spec isn't clear about the need for exceptions, it does state pretty clearly what NOT_VALIDATED is for, and the purpose doesn't include config or runtime errors.

IMO the whole "configuration errors" thing needs some more discussion and that's the main origin of these exceptions. A future version of the spec could probably add a new return value for network and pure runtime errors, but I wouldn't do it at this time.
We should update the spec at some point, to add statuses, exceptions, or both, but we clearly can't add new status values now because the spec is frozen.

  • Default searchFilters:
There's no default searchFilter for caller lookup, but there is one for group lookup. We should probably handle both the same way -- either provide a default, or don't. The right way to provide defaults would probably be on the annotation attributes, rather than buried in internal code, but it's too late for that change.

Given that, my bias is to remove the default group search filter, rather than add a new one for callers. Note that any default filter should probably include objectclass filtering, which is fairly straightforward for groups, but not quite as straightforward for callers -- there's a wider variety of "person" objectclasses, including, apparently, (objectclass=computer), which is necessary for some LDAPs but won't work for others.
I can't unfortunately comment on this since I have no LDAP experience.
Thanks for any thoughts you may have,

Will

-- 
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: Need to resolve outstanding issues with LdapIdentityStore

Guillermo González de Agüero
 

Hi,

El mar., 8 ago. 2017 a las 11:37, Will Hopkins (<will.hopkins@...>) escribió:
I've been looking at the pile of bugs currently filed against the default LdapIdentityStore in Soteria, and have noticed a couple broad themes. I'd appreciate some feedback on these ASAP, as we need to decide on a consistent approach so we don't end up with wildly inconsistent behavior for different scenarios.

I'm compiling a list in issue #165, but want to call your attention to a couple items in particular:
  • Returning NOT_VALIDATED vs. throwing an exception from validate():
My understanding to date has been that NOT_VALIDATED has a very specific meaning -- i.e., the identity store didn't attempt to validate the credential, because it doesn't handle that credential type. Errors -- network errors, config errors, etc. -- always result in a runtime exception being thrown.

This is reasonable if we expect errors to be rare, but the behavior isn't documented -- since there are no checked Exceptions, and we didn't add an explicit javadoc reference to runtime exceptions -- and it seems to happen pretty frequently since config problems don't typically fail deployment. This is the source of a lot of the outstanding bugs.

On balance, I'm leaning toward returning NOT_VALIDATED rather than throwing exceptions, and some fixes have already been made that catch exceptions rather than letting them propagate out of validate(). That said, I don't have really strong feelings either way -- we just need to pick one way or the other and handle errors consistently.
I prefer to throw exceptions at this moment so we can decide on a future version wether it's preferrable to create a VALIDATION_ERROR result, or if deployment validation is achievable and validation errors become rare.

IMO the whole "configuration errors" thing needs some more discussion and that's the main origin of these exceptions. A future version of the spec could probably add a new return value for network and pure runtime errors, but I wouldn't do it at this time.
  • Default searchFilters:
There's no default searchFilter for caller lookup, but there is one for group lookup. We should probably handle both the same way -- either provide a default, or don't. The right way to provide defaults would probably be on the annotation attributes, rather than buried in internal code, but it's too late for that change.

Given that, my bias is to remove the default group search filter, rather than add a new one for callers. Note that any default filter should probably include objectclass filtering, which is fairly straightforward for groups, but not quite as straightforward for callers -- there's a wider variety of "person" objectclasses, including, apparently, (objectclass=computer), which is necessary for some LDAPs but won't work for others.
I can't unfortunately comment on this since I have no LDAP experience.
Thanks for any thoughts you may have,

Will

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


Re: Testing JSec?

Guillermo González de Agüero
 

Exactly. As you may know, Java EE contained two specs related to security:
- JASPIC, for authentication
- JACC, for authorization

Aside of that, every spec contained its own security related features (e.g. getting caller principal, check if user is in specified role), since both JASPIC and JACC were too "platform-level" oriented.

This new Security API is just built on top of that two base specifications, aiming to provide a user friendly entry point. Since this version of the API handles basically only authentication (due to time constratints), JACC is hardly mentioned on the spec.

If you have some time, I highly recommend you read the spec [1] to fully understand the problems this is intended to solve. Again, any feedback on the wording will be appreciated.

Regards,

Guillermo González de Agüero


El mié., 9 ago. 2017 a las 22:19, Saeed (<sinaisix@...>) escribió:
Ah the proverbial light bulb has gone off in my head now. So the Security API essentially more or less is a layer on top of the disparate (?) existing security APIs in Java EE. More like consolidation?

I think I can find my way around more with that foundation in mind. Once again thanks. 

On 9 Aug 2017 20:00, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Hi,

Unfortunately this version of the spec didn't managed to implement the authorization part and basically only deals with authentication.

However the Servlet spec has since the beginning the security-constraint element in the web.xml deployment descriptor. This is the only standard way to restrict role access to pages.

You have some good information on the Java EE 7 tutorial: https://docs.oracle.com/javaee/7/tutorial/security-webtier002.htm

Where restricing based on roles, note that there are two special built-in ones, "*" and "**": 
- * means any authenticated user which has at least one role, whatever it is, is granted access.
-  ** means any autenticated user, even users without roles.


Regards,

Guillermo González de Agüero


El mié., 9 de agosto de 2017 21:51, Saeed <sinaisix@...> escribió:
Hi. I've been looking at the test examples and so far I'm able to follow them. However I'm at a loss about how to declare a specific set of say JSF pages as protected.


In Shiro, I can declare in the shiro.ini file that /foo/* is protected so only logged in users with certain roles can access it.

I'm not sure if I've seen such with JSec yet.  Again pardon me if I miss the obvious.

Thanks in advance
 


On 9 Aug 2017 17:46, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Saeed
 

Ah the proverbial light bulb has gone off in my head now. So the Security API essentially more or less is a layer on top of the disparate (?) existing security APIs in Java EE. More like consolidation?

I think I can find my way around more with that foundation in mind. Once again thanks. 

On 9 Aug 2017 20:00, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Hi,

Unfortunately this version of the spec didn't managed to implement the authorization part and basically only deals with authentication.

However the Servlet spec has since the beginning the security-constraint element in the web.xml deployment descriptor. This is the only standard way to restrict role access to pages.

You have some good information on the Java EE 7 tutorial: https://docs.oracle.com/javaee/7/tutorial/security-webtier002.htm

Where restricing based on roles, note that there are two special built-in ones, "*" and "**": 
- * means any authenticated user which has at least one role, whatever it is, is granted access.
-  ** means any autenticated user, even users without roles.


Regards,

Guillermo González de Agüero


El mié., 9 de agosto de 2017 21:51, Saeed <sinaisix@...> escribió:
Hi. I've been looking at the test examples and so far I'm able to follow them. However I'm at a loss about how to declare a specific set of say JSF pages as protected.


In Shiro, I can declare in the shiro.ini file that /foo/* is protected so only logged in users with certain roles can access it.

I'm not sure if I've seen such with JSec yet.  Again pardon me if I miss the obvious.

Thanks in advance
 


On 9 Aug 2017 17:46, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Guillermo González de Agüero
 

Hi,

Unfortunately this version of the spec didn't managed to implement the authorization part and basically only deals with authentication.

However the Servlet spec has since the beginning the security-constraint element in the web.xml deployment descriptor. This is the only standard way to restrict role access to pages.

You have some good information on the Java EE 7 tutorial: https://docs.oracle.com/javaee/7/tutorial/security-webtier002.htm

Where restricing based on roles, note that there are two special built-in ones, "*" and "**": 
- * means any authenticated user which has at least one role, whatever it is, is granted access.
-  ** means any autenticated user, even users without roles.


Regards,

Guillermo González de Agüero


El mié., 9 de agosto de 2017 21:51, Saeed <sinaisix@...> escribió:
Hi. I've been looking at the test examples and so far I'm able to follow them. However I'm at a loss about how to declare a specific set of say JSF pages as protected.


In Shiro, I can declare in the shiro.ini file that /foo/* is protected so only logged in users with certain roles can access it.

I'm not sure if I've seen such with JSec yet.  Again pardon me if I miss the obvious.

Thanks in advance
 


On 9 Aug 2017 17:46, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Arjan Tijms
 

Hi,

On Wednesday, August 9, 2017, Saeed <sinaisix@...> wrote:
Hi. I've been looking at the test examples and so far I'm able to follow them. However I'm at a loss about how to declare a specific set of say JSF pages as protected.

A specific set of JSF pages can be protected in web.xml using a security constraint.

Kind regards,
Arjan



 



In Shiro, I can declare in the shiro.ini file that /foo/* is protected so only logged in users with certain roles can access it.

I'm not sure if I've seen such with JSec yet.  Again pardon me if I miss the obvious.

Thanks in advance
 



 

On 9 Aug 2017 17:46, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Saeed
 

Hi. I've been looking at the test examples and so far I'm able to follow them. However I'm at a loss about how to declare a specific set of say JSF pages as protected.


In Shiro, I can declare in the shiro.ini file that /foo/* is protected so only logged in users with certain roles can access it.

I'm not sure if I've seen such with JSec yet.  Again pardon me if I miss the obvious.

Thanks in advance
 


On 9 Aug 2017 17:46, "Guillermo González de Agüero" <z06.guillermo@...> wrote:
Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Guillermo González de Agüero
 

Great to hear that! The tests are indeed the best way to get started right now.

We an to write some documentation but we're still busy finishing Soteria for its release in the next couple of weeks.

Please don't hesitate to ask for help on any doubt you have. And we will specially welcome any bug reports you can make.

Hope you enjoy!


Regards,

Guillermo González de Agüero

El mié., 9 de agosto de 2017 15:07, Saeed <sinaisix@...> escribió:
Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Saeed
 

Thanks. Got it to work. Checking out the samples in the RI code repo. I think I'm getting the hang of this, coming from the Apache Shiro way of thinking. Once again thanks everyone for your input

Luqman 

+233-504-733076



On 8 August 2017 at 17:48, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>



Re: Testing JSec?

Guillermo González de Agüero
 

Hi Saaed,

Thanks for your interest! As Will has already stated, latest promoted versions of GlassFish already integrate JSR 375, so you won't need Soteria dependency, just the API.

The latest version GlassFish has integrated is 1.0-b11 [1] so your dependency should be:

<dependency>
    <groupId>javax.security.enterprise</groupId>
    <artifactId>javax.security.enterprise-api</artifactId>
    <version>1.0-b11</version>
    <scope>provided</scope>
</dependency>

The problem you are finding is that artifacts are still not being uploaded to Maven Central, but to java.net, so you will need to add the Java.net Maven repository:

<repository>
    <id>java-net</id>
    <name>Java.net</name>
    <url>https://maven.java.net/content/repositories/releases/</url>
</repository>

GlassFish has just upgraded the version, so you should better try a nightly build if possible to benefit of the latest bugfixes.

Pleas don't forget to create issues for any bug or inconsistency you find!


Regards,

Guillermo González de Agüero

[1] https://github.com/javaee/glassfish/pull/22190/files



El mar., 8 ago. 2017 a las 19:33, Saeed (<sinaisix@...>) escribió:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>


Re: Testing JSec?

Saeed
 

Thank you very much Will. I've no idea why the Soteria repo never came to mind. 

Thanks so much. Off to play with it. 

On 8 Aug 2017 17:39, "Will Hopkins" <will.hopkins@...> wrote:
Hi Saeed,

The latest GF build should have Soteria in it already.

We have not published a recent "release" version of Soteria, or the API, although there are "promoted" builds and snapshots at maven.java.net. Also your pom.xml snippet is very out of date -- the GAV values are incorrect. Have a look at the current poms to see what they should look like.

https://javaee.github.io/security-spec/ is a good place to start getting familiar with the current state of the spec, API, and RI for JSR-375.

Thanks,

Will


On 08/08/2017 01:21 PM, Saeed wrote:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
            <groupId>javax.security</groupId>
            <artifactId>javax.security-api</artifactId>
            <version>1.0-m01</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.soteria</groupId>
            <artifactId>soteria</artifactId>
            <version>1.0-m01</version>
        </dependency>

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



Re: Testing JSec?

Will Hopkins
 

Hi Saeed,

The latest GF build should have Soteria in it already.

We have not published a recent "release" version of Soteria, or the API, although there are "promoted" builds and snapshots at maven.java.net. Also your pom.xml snippet is very out of date -- the GAV values are incorrect. Have a look at the current poms to see what they should look like.

https://javaee.github.io/security-spec/ is a good place to start getting familiar with the current state of the spec, API, and RI for JSR-375.

Thanks,

Will

On 08/08/2017 01:21 PM, Saeed wrote:
Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
            <groupId>javax.security</groupId>
            <artifactId>javax.security-api</artifactId>
            <version>1.0-m01</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.soteria</groupId>
            <artifactId>soteria</artifactId>
            <version>1.0-m01</version>
        </dependency>

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


Testing JSec?

Saeed
 

Hello everyone from Accra Ghana. I would like to test out Soteria with the just published Glassfish promoted build 18. However adding the following dependency to my pom.xml results in maven throwing an error saying it cannot locate the artifacts. Pardon my ignorance if the solution is something very simple. Thanks in advance. 

 <dependency>
<groupId>javax.security</groupId>
<artifactId>javax.security-api</artifactId>
<version>1.0-m01</version>
</dependency>
<dependency>
<groupId>org.glassfish.soteria</groupId>
<artifactId>soteria</artifactId>
<version>1.0-m01</version>
</dependency>


Need to resolve outstanding issues with LdapIdentityStore

Will Hopkins
 

I've been looking at the pile of bugs currently filed against the default LdapIdentityStore in Soteria, and have noticed a couple broad themes. I'd appreciate some feedback on these ASAP, as we need to decide on a consistent approach so we don't end up with wildly inconsistent behavior for different scenarios.

I'm compiling a list in issue #165, but want to call your attention to a couple items in particular:
  • Returning NOT_VALIDATED vs. throwing an exception from validate():
My understanding to date has been that NOT_VALIDATED has a very specific meaning -- i.e., the identity store didn't attempt to validate the credential, because it doesn't handle that credential type. Errors -- network errors, config errors, etc. -- always result in a runtime exception being thrown.

This is reasonable if we expect errors to be rare, but the behavior isn't documented -- since there are no checked Exceptions, and we didn't add an explicit javadoc reference to runtime exceptions -- and it seems to happen pretty frequently since config problems don't typically fail deployment. This is the source of a lot of the outstanding bugs.

On balance, I'm leaning toward returning NOT_VALIDATED rather than throwing exceptions, and some fixes have already been made that catch exceptions rather than letting them propagate out of validate(). That said, I don't have really strong feelings either way -- we just need to pick one way or the other and handle errors consistently.
  • Default searchFilters:
There's no default searchFilter for caller lookup, but there is one for group lookup. We should probably handle both the same way -- either provide a default, or don't. The right way to provide defaults would probably be on the annotation attributes, rather than buried in internal code, but it's too late for that change.

Given that, my bias is to remove the default group search filter, rather than add a new one for callers. Note that any default filter should probably include objectclass filtering, which is fairly straightforward for groups, but not quite as straightforward for callers -- there's a wider variety of "person" objectclasses, including, apparently, (objectclass=computer), which is necessary for some LDAPs but won't work for others.
Thanks for any thoughts you may have,

Will

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

101 - 120 of 736