Hi,
On Mon, Apr 10, 2017 at 11:02 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
>
> Was not "EE security API" but security in general. > 50% of cases I saw
> can justify to not use a "common" (read as "standard" API) cause the
> integration need is >> the gain due to company specific definition of
> security.
>
Ah, ok. I see what you mean.
Well, you'd be surprised still ;) It's maybe a little offtopic for this
thread, but for custom security in general by just standardising these two
age old existing artefacts - the authentication mechanism and the identity
store, you can implement a huge number of cases.
From stateless token authentication (
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html)
to Oath2 (
https://github.com/omnifaces/soteria-google-oauth-client) and JWT
(
https://github.com/rdebusscher/soteria-jwt).
Of course, there are always cases (the remaining 5%?) that will be hard to
do this way and will need to go way beyond the spec, but as a minimal JSR
375 offers a CDI based bean that can do "whatever" and then once it has
done this whatever just sets the authenticated identity into the container.
For the maybe 1% of cases were even this primitive cannot be used, another
approach has to be taken. So be it ;)
> I guess we can sadly say that JACC failed - no link to its quality in
> itself - since it didnt get any traction for user code, of course, but also
> libs (JTA is well integrated in a looot of libs).
>
I more or less agree with that, but the base is there and it actually only
needs a few nudges into the right direction to be much more usable.
See for example this POC I designed last year:
http://arjan-tijms.omnifaces.org/2016/07/simplified-custom-authorization-rules.html
> What I'm worrying about can be summarized mainly as 3 points:
>
I'm not 100% sure which of the points is about JACC and which are about JSR
375, but I'll try to answer to the best of my ability:
> 1. the API is quite complex for no obvious gain (ex: it relies on a kind
> state machine where most successful API don't - spring, deltaspike, shiro,
> ...)
>
With the state machine I take it you mean the one used by JACC for
configuration. Indeed, this would for the majority of cases not be needed
to be implemented by the user of JACC. And in fact, it doesn't have to. If
you only supply this fairly straightforward (straightforward for the JACC
spec requirement) JACC provider and let the user only override that what is
needed, things would already massively, massively be simplified:
https://github.com/arjantijms/jacc-provider/tree/master/src/main/java/org/omnifaces/jaccprovider
The point is that the "state machine" just collects the constraints from
the (web) application and each constraint is fed into the configuration
collector class as its encountered. But there's no logical need to let the
user implement this. A default configuration collector provided by the user
that gets passed-in all constraints in one go would work just as well.
Basically, a default implementation like this has to be provided:
https://github.com/arjantijms/jacc-provider/blob/master/src/main/java/org/omnifaces/jaccprovider/TestPolicyConfigurationStateMachine.java
So a user would only have to implement this:
https://github.com/arjantijms/jacc-provider/blob/master/src/main/java/org/omnifaces/jaccprovider/TestPolicyConfiguration.java
> 2. the API is quite bound to HTTP which makes the code quite hard to
> evolve very quickly
>
Do you mean JACC here or JSR 375? JACC is not so much bound to HTTP at all,
really. But web is the major use case these days. The JSR 375 EG has
decided to prioritise the web layer indeed. So it's
HttpAuthenticationModule, an Http specific CDI based specialisation of the
far more general ServerAuthModule.
> 3. @*Definition is quite crazy thinking about it if it doesn't provide
> some override (in the spec, not soteria)...and also includes passwords in
> clear.
>
So this is clearly about JSR 375 ;)
I know you in particular don't like @*Definition annotations, but it has to
be realised they are *not* central to JSR 375. They are -a- way to
introduce configured and enabled Beans into the application, but a third
party library absolutely does not have to follow this approach, and by
extension neither does a user application.
One could just as well define a Bean, enable it via beans.xml and inject
configuration into it (via, who knows, DeltaSpike ;)).
Nothing in the JSR prevents this. @*Definition just allows the user the
quickly configure and enable 3 pre-defined identity stores, namely the
Ldap, JDBC and embedded ones.
Password aliasing was high on the list of things to do, but, as much as I
dislike it, will likely have to be done as a vendor specific feature now
since we ran out of time. Thanks for reminding us though ;)
> 1 and 2 justifies my prudence, 3 is IMHO an abuse of @*Definition trend EE
> tried to use. Since security is 100% CDI based it could rely on an event +
> builder pattern (or anything fluent) which is more industriablizable and
> allow to read passwords/credentials in a safe manner or hardcode them for
> embed case (which is relatively rare for a ldap).
>
Again, there's absolutely nothing that prevents us to add this later. My
main preference would have been to have 3 options for configuration -
annotation (quick and easy), deployment descriptor (more externalised, but
still in archive), and programmatic (can do whatever).
Kind regards,
Arjan Tijms
>
> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>> (for good and bad reasons) and is easier not integrating with a 3rd
>>> party (EE or not) in other numerous cases to not pollute the web profile
>>> with yet another spec not yet helping much in enough cases.
>>>
>>> +1 to get it in the full profile however, it is a very good move and
>>> next version will hopefully make it more adapted to enterprises and
>>> microservices and could imply a move to webprofile if accepted enough.
>>>
>>> Probably wiser this way than the opposite which would enforce a stack
>>> for EE > 8 not yet justified IMHO.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://blog-rmannibucau.rhcloud.com> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
>>> <https://javaeefactory-rmannibucau.rhcloud.com>
>>>
>>> 2017-04-10 21:35 GMT+02:00 <ondrej.mihalyi_at_gmail.com>:
>>>
>>>> Hi Linda and Security JSR EG,
>>>>
>>>> I think that majority of the people who care would warmly welcome this
>>>> new security API also in Web Profile (many people already showed their
>>>> preference on Twitter:
>>>> https://twitter.com/delabassee/status/851486773058433026)
>>>>
>>>> However, I'd like to ask what are the implications? What other
>>>> dependencies would it bring to the WebProfile?
>>>>
>>>> E.g. the Security JSR depends on JASPIC, which is not part of Web
>>>> Profile. From the spec EDR1: " Integration with the servlet container
>>>> leverages JASPIC;
>>>> the container MUST configure and invoke the HttpAuthenticationMechanism
>>>> via JASPIC, as
>>>> described below"
>>>>
>>>> It seems to me that with the new Security JSR, also JASPIC needs to be
>>>> moved to Web Profile. Is it really necessary or can the dependency on
>>>> JASPIC be optional?
>>>>
>>>> I'd appreciate to make JASPIC optional and leave it out of Web Profile,
>>>> because it's a cumbersome API and not really needed to be exposed in
>>>> the Web Profile.
>>>>
>>>> Ondrej
>>>>
>>>
>>>
>>
>