Date
1 - 11 of 11
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>
|
|
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. -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803
|
|
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:
|
|
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.<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> Pleas don't forget to create issues for any bug or inconsistency you find!
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.
|
|
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:
|
|
Guillermo González de Agüero
Great to hear that! The tests are indeed the best way to get started right now.
toggle quoted messageShow quoted text
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ó:
|
|
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.
|
|
Hi,
On Wednesday, August 9, 2017, Saeed <sinaisix@...> wrote:
A specific set of JSF pages can be protected in web.xml using a security constraint. Kind regards, Arjan
|
|
Guillermo González de Agüero
Hi,
toggle quoted messageShow quoted text
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ó:
|
|
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,
|
|
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ó:
|
|