users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Re: Comments on Current Spec Content (take 3)

From: Rudy De Busscher <rdebusscher_at_gmail.com>
Date: Thu, 23 Feb 2017 12:09:19 +0100

Arjan,

It is true that I have used the EmbeddedIdentityStoreDefinition for
**demos**, so that I and the audience can focus on the other parts of Java
EE Security/Soteria.

And I do like it for **presentations* *but hope that no one uses the store
in production situations. That is why I also, always say that it is a demo
and not necessarily a good thing to do in a production situation.

And therefore I also think it is best that we remove it from the spec. The
implementors can always add it as a convenient aid if they want to help the
developers to prepare something quickly for a demo.

But adding it to the spec, maybe suggest that the EG members agree that it
is a best practice.

PS. My understanding about using files and EJB is that writing files is not
transactional and thus not allowed. (Or you need to create a RAR for that)
But I can't see what is wrong with reading files.

best regards
Rudy

On 23 February 2017 at 10:35, arjan tijms <arjan.tijms_at_gmail.com> wrote:

> Hi,
>
> I'm not 100% sure yet. How is it really different from
> @DataSourceDefinition?
>
> A bit of the issue is that Java EE has problems scaling down, because it
> historically has been holding the hands of the developers a bit too much.
> I.e. having your services in a separate module and giving them an interface
> was seen as a best practice, so EJB mandated this.
>
> Reading files was seen as bad, so EJB prohibited this.
>
> But all of that was seen as heavy and cumbersome, so developers avoided
> EJB and used "lighter" alternatives. Then in EJB 3.1 and 3.2 these
> restrictions were lifted.
>
> The EmbeddedIdentityStoreDefinition is already used by people for demos
> (including by my friend Rudy :P), because it's simply much easier to setup
> than a database version, let alone an LDAP store.
>
> The proposal for the EmbeddedIdentityStoreDefinition came from Reza
> Rahman, so perhaps it's best if he could comment here.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
> On Thu, Feb 23, 2017 at 7:46 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>
>> I agree that we should move the
>>
>> EmbeddedIdentityStoreDefinition
>>
>> To the Soteria implementation (not part of the spec itself) as it is not
>> something that we should promote from the EG.
>>
>> Best regards
>>
>> Rudy
>>
>>
>>
>> On 21 February 2017 at 16:09, Brian Demers <brian.demers_at_gmail.com>
>> wrote:
>>
>>> 2.7 Build-in Identity Store Beans
>>>>>
>>>>> - Embedded -- annotation only? No support for deploying a file or
>>>>> other mechanism? Safety of embedding passwords in file or in code
>>>>> (annotation)?
>>>>>
>>>>>
>>>> Good points! For the moment it's annotation only, but files are indeed
>>>> very common (I put some examples of those here:
>>>> https://dzone.com/refcardz/getting-started-java-ee).
>>>>
>>>> It should indeed be made abundantly clear that the annotation is
>>>> intended for testing / demo purposes, and not normally suited for
>>>> production usage.
>>>>
>>>>
>>>> Agreed.
>>>>
>>>
>>> I disagree, I think these should be removed, anything that can be used
>>> will be used. This would force other implementations to _support_ these
>>> annotations, which seems superficial (only used for demos), and a bad
>>> idea. I personally think, if this annotation is to be kept at all it
>>> should be moved into a different package (org.glassfish.soteria).
>>>
>>> Embedding passwords in code like this (which I'm sure would be posted in
>>> blogs and forums) will shine a bad light onto this effort, and the results
>>> will be negative, and thus hurt adoption.
>>>
>>
>>
>