users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Re: EG logistics

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Mon, 9 Mar 2015 23:28:47 +0100

Hi,

On Mon, Mar 9, 2015 at 10:49 PM, Les Hazlewood <les_at_stormpath.com> wrote:
> I think creating Jira issues before a high level outline or 'epics' or
> 'stories' (or 'topics' and 'sub topics') are defined is backwards.
> Shouldn't we all be on the same page and have an understanding of the higher
> level picture and (general) topics/sub-topics before we go debating specific
> features and tasks?

It depends really, in some cases you want to have some big upfront
design to see the bigger picture and it other cases you don't.

In the (somewhat) lengthy discussion in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-10 I indeed
mentioned at some point:

"I do think it's especially important to establish some terminology
and to take a look at how all individual ideas come together as a
whole."

In other cases, a collection of small requirements does give you an
idea of where to go.

For instance, "authentication events" is by itself a pretty clear wish
IMHO, and that those events should be observable by CDI is pretty
clear too. Now the details of who is going to throw the event exactly
are still to be discussed, as are details regarding what the event
looks like, and whether a listener can or cannot influence the
authenticate outcome etc.

For what it's worth, OmniFaces simplified JSF without much if any
upfront designs. It's a collection of utility methods that taken all
together fill a lot of holes in the JSF spec and arguably makes JSF a
lot more fun to use.

I think a lot of the security problems can be solved in that way as
well. For instance, one problem is that the user/caller and
group/roles Principals in Java EE are not standardized. So lets look
at defining two standard principals for that. Another problem is that
asking the question "Will the user have access to this URL?" requires
a lot of code. So let's introduce a small utility method for that very
question so it's just one call. Etc etc.

Kind regards,
Arjan Tijms




 The JSR is a good start, but too high level, and Jira
> issues are too low level (IMHO). More, they are myopic: when looking at a
> single jira issue, I can't see how it relates to other issues, where it
> aligns with other issues in its 'category', or where it fits in the general
> scheme of things.
>
> In other words, Jira is an issue tracker - it is marginal at best for
> feature management (whereas, Confluence - as just one of many examples - is
> better for that).
>
> My .02,
>
> Les