add a proposal for a SecurityBindingType

[struberg]

With SecurityBindingType you can easily add your own security logic as cross cutting concerns similar to CDI Interceptors.

[arjantijms]

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a CDI based "@RolesAllowed" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer to the "@EvaluateSecured" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization)?

@dblevins Should be perhaps already start thinking about organization of this repo? A first level "authentication" and "authorization" perhaps? Then authentication organized in "mechanism" and "store" (even though we don't have a final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and how it fits into the grand scheme of things? Maybe Rudy's mindmap and my diagram can be of help here too.

[struberg]

Hi Arjan!

The SecurityBindingType is neither Role nor Permission based actually. It allows for a flexible integration on whatever level your company needs. In fact I basically almost always had a mixture of roles and permissions to check for. Often they are also tenant specific! And sometimes there are multiple AND vs OR requirements as well.
So it basically boils down to being a VERY company and business related topic. And this is what is really the strength of this approach. It allows to add any payload you like to your security annotation. Much like with Interceptor annotations can get any payload you like.

LieGrue,
strub

PS: if my mail doesn’t make it through to the spec list then plz forward it for me - txs!

Am 25.03.2015 um 13:34 schrieb Arjan Tijms notifications@github.com:

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a CDI based "@RolesAllowed" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer to the "@EvaluateSecured" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization)?

@dblevins Should be perhaps already start thinking about organization of this repo? A first level "authentication" and "authorization" perhaps? Then authentication organized in "mechanism" and "store" (even though we don't have a final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and how it fits into the grand scheme of things? Maybe Rudy's mindmap and my diagram can be of help here too.

—
Reply to this email directly or view it on GitHub.

[struberg]

Hi,

On Wed, Mar 25, 2015 at 2:54 PM, Mark Struberg struberg@yahoo.de wrote:

The SecurityBindingType is neither Role nor Permission based actually. It
allows for a flexible integration on whatever level your company needs. In
fact I basically almost always had a mixture of roles and permissions to
check for. Often they are also tenant specific! And sometimes there are
multiple AND vs OR requirements as well.
So it basically boils down to being a VERY company and business related
topic. And this is what is really the strength of this approach. It allows
to add any payload you like to your security annotation. Much like with
Interceptor annotations can get any payload you like.

I sounds good ;)

How do you propose to position such annotation relative to (CDI based)
@RolesAllowed and (EL based) @EvaluateSecured?

And how would we explain to users the benefit of this annotation vs a
"regular" Interceptor annotation, where as you mentioned users can already
provide any payload they like (which therefor can be security related as
well in a way that's totally application specific)?

Note, this is no criticism, just wondering how to fit this into the larger
picture.

Kind regards,
Arjan Tijms

LieGrue,
strub

PS: if my mail doesn’t make it through to the spec list then plz forward
it for me - txs!

Am 25.03.2015 um 13:34 schrieb Arjan Tijms notifications@github.com:

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a CDI
based "@RolesAllowed" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer
to the "@EvaluateSecured" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization
)?

@dblevins Should be perhaps already start thinking about organization of
this repo? A first level "authentication" and "authorization" perhaps? Then
authentication organized in "mechanism" and "store" (even though we don't
have a final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and
how it fits into the grand scheme of things? Maybe Rudy's mindmap and my
diagram can be of help here too.

—
Reply to this email directly or view it on GitHub.

[alexkosowski]

@dblevins https://github.com/dblevins Should be perhaps already
start thinking about organization of this repo? A first level
"authentication" and "authorization" perhaps? Then authentication
organized in "mechanism" and "store" (even though we don't have a
final term for that last one yet).
Sounds like these would be the expected, reasonable security categories,
certainly reasonable for a repo.

Alex

On 3/25/15 8:34 AM, Arjan Tijms wrote:

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a
CDI based "@RolesAllowed" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this
closer to the "@EvaluateSecured" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization)?

@dblevins https://github.com/dblevins Should be perhaps already
start thinking about organization of this repo? A first level
"authentication" and "authorization" perhaps? Then authentication
organized in "mechanism" and "store" (even though we don't have a
final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and
how it fits into the grand scheme of things? Maybe Rudy's mindmap and
my diagram can be of help here too.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[struberg]

In my opinion @RolesAllowed is often not enough. The strict String[] role based mode is one of the reason EE-security is not used that often. In practice I almost always needed more. It is kind of a meta-framework and you can of course build @RolesAllowed as a @SecurityBindingType as well ;)

It can be implemented via CDI - but also via Spring, etc.

And how would we explain to users the benefit of this annotation vs a „regular“ Interceptor annotation
That’s indeed a good question.
In DeltaSpike it technically IS kind of an interceptor of course. The difference is that you cannot use it as manual interceptor but it’s always explicitly used by and for security checks.

LieGrue,
strub

Am 25.03.2015 um 15:36 schrieb arjan tijms arjan.tijms@gmail.com:

Hi,

On Wed, Mar 25, 2015 at 2:54 PM, Mark Struberg struberg@yahoo.de wrote:
The SecurityBindingType is neither Role nor Permission based actually. It allows for a flexible integration on whatever level your company needs. In fact I basically almost always had a mixture of roles and permissions to check for. Often they are also tenant specific! And sometimes there are multiple AND vs OR requirements as well.
So it basically boils down to being a VERY company and business related topic. And this is what is really the strength of this approach. It allows to add any payload you like to your security annotation. Much like with Interceptor annotations can get any payload you like.

I sounds good ;)

How do you propose to position such annotation relative to (CDI based) @RolesAllowed and (EL based) @EvaluateSecured?

And how would we explain to users the benefit of this annotation vs a "regular" Interceptor annotation, where as you mentioned users can already provide any payload they like (which therefor can be security related as well in a way that's totally application specific)?

Note, this is no criticism, just wondering how to fit this into the larger picture.

Kind regards,
Arjan Tijms

LieGrue,
strub

PS: if my mail doesn’t make it through to the spec list then plz forward it for me - txs!

Am 25.03.2015 um 13:34 schrieb Arjan Tijms notifications@github.com:

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a CDI based "@RolesAllowed" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer to the "@EvaluateSecured" (as proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization)?

@dblevins Should be perhaps already start thinking about organization of this repo? A first level "authentication" and "authorization" perhaps? Then authentication organized in "mechanism" and "store" (even though we don't have a final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and how it fits into the grand scheme of things? Maybe Rudy's mindmap and my diagram can be of help here too.

—
Reply to this email directly or view it on GitHub.

[rdebusscher]

I added an alternative where you can use NamedPermissions, which is more fine grained then roles (like you can have implied permisions). see https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/named-permissions.

It defines @PermissionsRequired as counterpart for @RolesAllowed.

[arjantijms]

Hi,

On Friday, March 27, 2015, Rudy De Busscher notifications@github.com
wrote:

I added an alternative where you can use NamedPermissions, which is more
fine grained then roles (like you can have implied permisions). see
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/named-permissions
.

It defines @PermissionsRequired as counterpart for @RolesAllowed.

Please do keep in mind that "Permission" is already used in Java EE
security. If we define it for something strongly related but still mening
something completely different, then this may make the terminology story
even more difficult.

Also, if we standardise group to role mapping, then a role will be actually
be that finer grained thing, and the group the coarser grained thing.

Kind regards,
Arjan Tijms

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[struberg]

Hi,

On Friday, March 27, 2015, Mark Struberg struberg@yahoo.de wrote:

In my opinion @RolesAllowed is often not enough. The strict String[] role
based mode is one of the reason EE-security is not used that often.

I see it a bit different. My own opinion and that what I've heard from
(many) others is that @RolesAllowed en web.xml constraints are easy to use
and have been sufficient.

In other words, defining the authorization constraint is not the major
issue.

IMHO, the major issue is the configuration of authentication stores (which
is mostly vendor specific) and the definition + configuration of
authentication mechanisms (which people think is vendor specific since we
perhaps didn't do the best job in the world to tell developers JASPIC
exists).

Then there are various gaps, like the non-standardised role mapper and
non-standardised caller- and group principals.

Of course it's great to have some modern or higher level features like
remember me, OAuth, events, CDI support etc, but I don't think the absence
of that is the core "flaw" in Java EE security.

That said, I do absolutely agree we should provide the "more" that you
mentioned to keep Java EE security relevant in the future.

Kind regards,
Arjan Tijms

In practice I almost always needed more. It is kind of a meta-framework
and you can of course build @RolesAllowed as a @SecurityBindingType as well
;)

It can be implemented via CDI - but also via Spring, etc.

And how would we explain to users the benefit of this annotation vs a
„regular“ Interceptor annotation
That’s indeed a good question.
In DeltaSpike it technically IS kind of an interceptor of course. The
difference is that you cannot use it as manual interceptor but it’s always
explicitly used by and for security checks.

LieGrue,
strub

Am 25.03.2015 um 15:36 schrieb arjan tijms <arjan.tijms@gmail.com
javascript:;>:

Hi,

On Wed, Mar 25, 2015 at 2:54 PM, Mark Struberg <struberg@yahoo.de
javascript:;> wrote:
The SecurityBindingType is neither Role nor Permission based actually.
It allows for a flexible integration on whatever level your company needs.
In fact I basically almost always had a mixture of roles and permissions to
check for. Often they are also tenant specific! And sometimes there are
multiple AND vs OR requirements as well.
So it basically boils down to being a VERY company and business related
topic. And this is what is really the strength of this approach. It allows
to add any payload you like to your security annotation. Much like with
Interceptor annotations can get any payload you like.

I sounds good ;)

How do you propose to position such annotation relative to (CDI based)
@RolesAllowed and (EL based) @EvaluateSecured?

And how would we explain to users the benefit of this annotation vs a
"regular" Interceptor annotation, where as you mentioned users can already
provide any payload they like (which therefor can be security related as
well in a way that's totally application specific)?

Note, this is no criticism, just wondering how to fit this into the
larger picture.

Kind regards,
Arjan Tijms

LieGrue,
strub

PS: if my mail doesn’t make it through to the spec list then plz forward
it for me - txs!

Am 25.03.2015 um 13:34 schrieb Arjan Tijms <notifications@github.com
javascript:;>:

Just wondering how to categorize this example.

It's an authorization example it seems, but is this an example of a
CDI based "@RolesAllowed" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-23), or is this closer
to the "@EvaluateSecured" (as proposed in
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 see also
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/el-authorization
)?

@dblevins Should be perhaps already start thinking about organization
of this repo? A first level "authentication" and "authorization" perhaps?
Then authentication organized in "mechanism" and "store" (even though we
don't have a final term for that last one yet).

At least make people a bit aware of what they are exactly demoing, and
how it fits into the grand scheme of things? Maybe Rudy's mindmap and my
diagram can be of help here too.

—
Reply to this email directly or view it on GitHub.

[rdebusscher]

Maybe not the location to discuss this (should be done at some point on the jsr375 mailing list)

But the role and group thing, even standardised, doesn't include the implied Thing (read permission or whatever name) or hierarchical structure. or will it?

If I have 1200 "Roles" in my application, I don't want to assign 1200 "Groups" to the User and have to define the mapping between them. (And I once had so it is real world situation)

to be continued on the mailing list later on when we are further with the Role-Group mapping.

[arjantijms]

Hi,

On Friday, March 27, 2015, Rudy De Busscher notifications@github.com
wrote:

Maybe not the location to discuss this (should be done at some point on
the jsr375 mailing list)

But the role and group thing, even standardised, doesn't include the
implied Thing (read permission or whatever name) or hierarchical
structure. or will it?

If I have 1200 "Roles" in my application, I don't want to assign 1200
"Groups" to the User and have to define the mapping between them. (And I
once had so it is real world situation)

Okay, let's discuss this somewhere on the list in more detail, but to round
up here;

Group to role mapping is many-to-many, typically one-to-many. One group can
(and often does) map to tens to hundreds of roles.

Kind regards,
Arjan Tijms

to be continued on the mailing list later on when we are further with the
Role-Group mapping.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[struberg]

Am 27.03.2015 um 13:08 schrieb arjan tijms arjan.tijms@gmail.com:

On Friday, March 27, 2015, Mark Struberg struberg@yahoo.de wrote:
In my opinion @RolesAllowed is often not enough. The strict String[] role based mode is one of the reason EE-security is not used that often.

I see it a bit different. My own opinion and that what I've heard from (many) others is that @RolesAllowed en web.xml constraints are easy to use and have been sufficient.

At least for all the 0.2% JavaEE programmer who are using it ;)
Of course I’m joking, but there is some truth in it ;)
I can only tell you that a simple String[] was not enough for almost all big projects I’ve been working on.

IMHO, the major issue is the configuration of authentication stores

I totally agree with you on this one. I still wonder why there is no portable way to register a LoginModule. Otoh once you have the auth activated then it’s most times just a matter of httpServletRequest.getRemoteUser() or getUserPrincipal().

Btw I personally feel that JASPIC is way too complicated and also too limited (n-factor authz missing, etc). But I’m no expert in that area.

LieGrue,
strub

[arjantijms]

Hi,

On Fri, Mar 27, 2015 at 6:00 PM, Mark Struberg notifications@github.com
wrote:

Of course I’m joking, but there is some truth in it ;)

It sure would be interesting to see what the numbers would approximately
be. There's no doubt in my mind that Spring Security and Shiro are used a
lot, and that home grown filter/request-wrapping based security is used in
far too many cases.

I can only tell you that a simple String[] was not enough for almost all

big projects I’ve been working on.

What I often saw is that there's a container specific or home grown
group-to-role mapping used (i.e. group "admin" maps to roles "edit_page",
..., "see_new_users", and sometimes to the group name as well, so "admin"
here).

Then URLs are protected by roles, and methods with @RolesAllowed if
possible. If more elaborate checks are needed the programmatic
isUser/CallerInRole is used (e.g. combinations of AND and OR of several
roles).

With JACC in the background you can "rather easily" (when you have JACC
setup and running) do things like {"see_new_users" is only valid during
week days from 9 to 5} without having that check in your code, and thus
having a fully transparent time-based role. (our friends from TMaxSoft have
a good example for that). I'm aware though that JACC is not trivial to
implement and register in the first place.

But the 2-level role hierarchy and the programmatic AND/OR/other gives you
a base amount of flexibility, with which you can express surprisingly many
things. And that it's not perfect is the reason we're talking right now in
this EG ;)

I still wonder why there is no portable way to register a LoginModule.

Well, actually there is (more or less). JASPIC does define how JAAS
LoginModules are integrated/registered in a portable way. It's called the
LoginModule Bridge profile, see e.g.
https://blogs.oracle.com/nasradu8/entry/loginmodule_bridge_profile_jaspic_in

This works to some degree (I know it's not perfect), but the next big
problem is that JAAS LoginModules themselves are not fully standardized
(see
http://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html
)

And then the problem after that is that the default Servlet authentication
mechanisms (FORM, BASIC, etc..) are not JASPIC based, so if you want to
used JAAS LoginModules with these the bridge profile is of no use.

I tried to sum up most of this here:
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-19

Otoh once you have the auth activated then it’s most times just a matter
of httpServletRequest.getRemoteUser() or getUserPrincipal().

Btw I personally feel that JASPIC is way too complicated

The SAM, which is the only thing a user should implement, is really not
that complicated. When you really look at it, it's just a kind of
ServletFilter with the extra feature that it gets an object from the
container that it can use to communicate the username and roles of the
logged-in user. Now what's complicated about that?

I provided an example a couple of times on the list (see
http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html)
that I personally think is almost as simple as you can get. Of course we
can discuss if that is indeed the case ;)

and also too limited (n-factor authz missing, etc). But I’m no expert in

that area.

You mean like 2-factor authentication? I implemented a SAM using that here:
https://github.com/arjantijms/two-factor-sam/blob/master/src/main/java/net/eisele/glassfish/twofactorsam/TwoFactorServerAuthModule.java

Actually providing such a SAM by default might be more of a job of this EG.
JSR 196 (JASPIC) is mainly for providing the low-level machinery. You
wouldn't e.g. fault Servlet for not providing JSF, would you? ;)

Kind regards,
Arjan Tijms

LieGrue,
strub

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[alexkosowski]

Hi Mark,

At least for all the 0.2% JavaEE programmer who are using it ;)
Of course I’m joking, but there is some truth in it ;)
I can only tell you that a simple String[] was not enough for almost all big projects I’ve been working on.

Is there something we could standardize that the 99.8% of the other JavaEE programmers are using? ;)

Regards,
Alex

[struberg]

This is exactly the point for using an additional indirection with the @SecurityBindingType.

@SecurityBindingType
public @interface MyVeryOwnCustomSecurityBinding {
String[] roles;
String tenant;
String[] location;
String whateverInfo;
}

Means you can define your OWN set of data which you need to make a decision whether some action is allowed or not.

Of course this internally might use some other framework like Shiro, PicketLink, etc.
This part of the proposal is targeting the data payload and not so much the security implementation of the Voter.

LieGrue,
strub

Am 28.03.2015 um 15:01 schrieb Alex Kosowski notifications@github.com:

Hi Mark,

At least for all the 0.2% JavaEE programmer who are using it ;)
Of course I’m joking, but there is some truth in it ;)
I can only tell you that a simple String[] was not enough for almost all big projects I’ve been working on.

Is there something we could standardize that the 99.8% of the other JavaEE programmers are using? ;)

Regards,
Alex

—
Reply to this email directly or view it on GitHub.

[arjantijms]

Means you can define your OWN set of data which you need to make a decision whether some action is allowed or not.

I see how that can be useful, but I don't yet see what the Java EE security API can offer to support this, especially if the implementation of the user provided interceptor might use Shiro etc.

Today a user can already define a custom interceptor, and a user can already use Shiro in that interceptor.

Sorry if I missed something in your proposal.

[alexkosowski]

It would seem the interceptor proposed in https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-7 would offer more flexibility. Using EL in the interceptor would allow authorization rules to be based on a variable set of attributes referring to managed beans. Also, we could extend the interceptor to allow external storage of EL rules, for example in LDAP.

I do have concerns about performance, processing EL per interceptor. But there may be optimizations.