All,
I guess aside from simply keeping those kinds of 3rd party examples or PoC
projects in everybody's seperate repositories, we could imagine something
along the lines of what JSR 354 did in "Shelter"
https://github.com/JavaMoney/javamoney-shelter
It was meant to foster initiatives like "Adopt a JSR" (hence the name) but
is not restricted to JUGs or their members adopting the JSR. If David and
Alex think, something similar (under whatever name, at the moment
"proposals" is also more or less a "sandbox" but it's for the actual JSR
components themselves) was a good idea to have in the GitHub organization,
I'm sure, they should be able to create something. Similar to using some or
all aspects of certain JSRs Spring may or will use this JSR sooner or later
(to become "somewhat compatible;-) but it is not the core task of the EG to
ensure every container or framework out there supports it as Arjan said.
Kind Regards,
Werner
On Tue, Dec 29, 2015 at 1:07 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi Rudy,
>
> Thanks for the effort you put in that example.
>
> The identity store proposal should indeed be usable by many technologies,
> since it really only defines the {credential in -> name/groups out}
> function. Like a (generic) DAO interface, it doesn't itself have much
> dependencies.
>
> On the other hand, I think we should watch out that "should be usable
> outside EE, should be usable by Spring, Shiro, what have you" doesn't
> become a core requirement. The problem is that wanting to be everything for
> everyone is what too often has made designs too abstract and too
> complicated.
>
> So IMHO this JSR should first and foremost make security easier and more
> straightforward to use in Java EE.
>
> But that said, nice example that you provided ;)
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> On Mon, Dec 28, 2015 at 11:55 AM, Rudy De Busscher <rdebusscher_at_gmail.com>
> wrote:
>
>> Hi all,
>>
>> I think an important aspect of the work we do, is that it is
>> compatible/can be used in existing 3th party security libraries.
>> Because a lot of developers are using them today and if the security
>> library is integrating the JSR375 code, the adoption will be
>> faster/smoother/better/....
>>
>> Therefore, I tried the integration between *Octopus* (the Java EE
>> security framework that I have developed over the last few years) and the *Identity
>> store proposal Arjan made* (
>> https://github.com/arjantijms/mechanism-to-store-x)
>>
>> I used the jsr375 module and wrote a *CredentialsMatcher* that uses the
>> *IdentityStore* defined by a definition annotation (in the example the
>> embedded one but any definition will work)
>>
>> The result can be seen in this repostory
>> https://github.com/rdebusscher/octopus-jsr375 (starterEE7 module)
>>
>> It works like a charm, of course due to the CDI nature of the
>> IdentityStore. :)
>> The code is quit generic, so I can create in the future a specific maven
>> artifact for the integration with the IdentityStore.
>>
>> Since the CredentialsMatcher is only depending on *Apache Shiro* (and
>> not Octopus), also Apache Shiro can make use of the IdentityStore.
>>
>> Best regards
>> Rudy
>>
>>
>>
>>
>