Aerogear security updates + ideas

[Bruno Oliveira]

Hi folks, I had some few simple ideas on aerogear security and I want to share them. 

I did some replacements with CDI interceptors to get rid of all Resteasy dependencies, because it was a lightweight way to integrate with aerogear controller (inspired on SecurityInterceptor from DeltaSpike) and started to write users/roles permissions (it's really simple)

Shane started discussions about DELTASPIKE-79(Authorization API http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/DISCUSS-DELTASPIKE-79-Authorization-API-Permission-Management-and-ACLs-td4579972.html) that's a good approach and I would like to use only this module when it get ready. Is it possible?

I would like to use DeltaSpike as a security authentication/authorization provider, but don't want to get tied aerogear-controller to DeltaSpike interceptor and annotations. To replace stuff like this https://github.com/abstractj/aerogear-security/blob/master/src/main/java/org/jboss/aerogear/security/idm/authentication/IdentityImpl.java#L61

Can I get the benefits of the Authorization API without getting tied to DeltaSpike? What do you think?

Further references:

https://github.com/abstractj/aerogear-security/blob/master/SECURITY.md

https://github.com/abstractj/aerogear-controller/tree/master/aerogear-controller-demo

--

-- 
"Know the rules well, so you can break them effectively" - Dalai Lama XIV
-
@abstractj
-
Volenti Nihil Difficile

[Lincoln Baxter, III]

Hey Bruno,

Why do you want to avoid using DeltaSpike annotations in the Aerogear framework?

As far as I know, DeltaSpike is the direct upstream of JDF, so these annotations will be used directly in other JBoss frameworks. I'm not sure it makes sense to fork this project just to avoid the name, particularly given the above, and the fact that DeltaSpike is intended to be a centralized defacto-standard place for CDI functionality and extensions. Effectively, I'm not sure you should be worried about being tied to DeltaSpike.

What are your thoughts about this? Pete, Jason, Shane?

Thanks,
Lincoln

--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

[Jason Porter]

+1

It would almost be like saying you want fork JPA because you don't want to use the annotations :) I don't see any reason for doing so. If it's because the features aren't there yet, help us get there sooner :)

On Wed, May 9, 2012 at 6:45 AM, Pete Muir <pm...@bleepbleep.org.uk> wrote:

As Lincoln says. If you don't want to be "tied to Deltaspike" then we have a much larger problem to resolve.

Can you elaborate on why you don't want to use DeltaSpike?

--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu

[Jay Balunas]

Just to be clear this is just a fairly minor PoC, not a concrete direction or impl.  We're not forking anything, and Bruno's just exploring various options, and wanted to talk about them. 

We have been discussing if it makes sense to abstract DeltaSpike as one of the possible security options.  I.e. will every user want to use DeltaSpike, or should that be plugable.  As I said it is a debate, and we wanted to discuss it, see if made sense etc...  I see pros/cons in both directions.  

But that is just part of the questions and comments from Bruno.  He also has questions about the authorization API, and other items.  

Lets not turn this into an argument about DeltaSpike, or not DeltaSpike.  Deltaspike is the primary security provider, we're just figuring out how to integrate, and collaborate on it.

[Pete Muir]

As Lincoln says. If you don't want to be "tied to Deltaspike" then we have a much larger problem to resolve.

Can you elaborate on why you don't want to use DeltaSpike?

On 9 May 2012, at 13:39, Lincoln Baxter, III wrote:

[Pete Muir]

Deltaspike should be the security API not the security provider.

[Pete Muir]

We, as a, group have worked too long and too hard on a strategy to provide a unified API for our ecosystem to let this just drop.

[Jason Porter]

DeltaSpike will eventually provide multiple implementations besides the default. Of course if you want to try something, extend the interface, that's certainly allowable, in fact I'd say even encouraged because it brings up ideas we haven't covered or have done poorly.

[Pete Muir]

+1, then contribute it back :-)

BUT DO NOT ABSTRACT IT OUT.

[Mike Brock]

[Jay Balunas]

On Wednesday, May 9, 2012 9:27:18 AM UTC-4, Pete wrote:

+1, then contribute it back :-)

This is exactly part of what we wanted to do here, there were some items that Bruno identified in phase 3/4 that he offered and wanted to prototype.  Always with the intention of contribute those back, and working with the Delta Spike team as he has been.  Nothing has changed there.

 

BUT DO NOT ABSTRACT IT OUT.

Separate out the abstraction conversation, as I mentioned that is an item to discuss (not the whole conversation).  Clearly there are some very strong opinions, and we're flexible.  

I think some of the uncertainty is around what delta spike will provide in the future.  Plug-able impls. are important, and so as Jason mentioned that is something to consider.  In fact I would say that the feedback here will be similar to what you might get from new users - do I need to abstract this, or is this everything I need.  

I can tell you its kind of tough to come here with ideas and have them jumped on like this.  I realize that is part of the party :-), but  as I mention in my reply its something we wanted to discuss.  Security is huge topic, we're not trying to recreate it, just working to see how to best integration.  

[Mark Little]

Would like to understand the pros and cons. I don't understand the
reasoning behind wanting to abstract DeltaSpike, so instead of jumping
to conclusions I'd like to get more facts.

Thanks,

Mark.

> >>http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/...)

> >> that's a good approach and I would like to use only this module when it get
> >> ready. Is it possible?
>
> >> > I would like to use DeltaSpike as a security
> >> authentication/authorization provider, but don't want to get tied
> >> aerogear-controller to DeltaSpike interceptor and annotations. To replace
> >> stuff like this

> >>https://github.com/abstractj/aerogear-security/blob/master/src/main/j...

>
> >> > Can I get the benefits of the Authorization API without getting tied to
> >> DeltaSpike? What do you think?
>
> >> > Further references:
>
> >> >https://github.com/abstractj/aerogear-security/blob/master/SECURITY.md
>

> >>https://github.com/abstractj/aerogear-controller/tree/master/aerogear...

[Jason Porter]

On Wed, May 9, 2012 at 7:44 AM, Jay Balunas <tec...@gmail.com> wrote:

On Wednesday, May 9, 2012 9:27:18 AM UTC-4, Pete wrote:

+1, then contribute it back :-)

This is exactly part of what we wanted to do here, there were some items that Bruno identified in phase 3/4 that he offered and wanted to prototype.  Always with the intention of contribute those back, and working with the Delta Spike team as he has been.  Nothing has changed there.

 

BUT DO NOT ABSTRACT IT OUT.

Separate out the abstraction conversation, as I mentioned that is an item to discuss (not the whole conversation).  Clearly there are some very strong opinions, and we're flexible.  

I think some of the uncertainty is around what delta spike will provide in the future.  Plug-able impls. are important, and so as Jason mentioned that is something to consider.  In fact I would say that the feedback here will be similar to what you might get from new users - do I need to abstract this, or is this everything I need.  

I can tell you its kind of tough to come here with ideas and have them jumped on like this.  I realize that is part of the party :-), but  as I mention in my reply its something we wanted to discuss.  Security is huge topic, we're not trying to recreate it, just working to see how to best integration.  

Sorry for that, I think we jumped quickly at the words. It certainly seems now we're all on the same page and understanding.

[Pete Muir]

I would suggest that rather than starting with the question "how do I abstract this out", we instead discuss what you want to achieve.

If you start a conversation half way through, based on premises that you know there are strong objections to, don't be surprised that people react badly.

For example, perhaps you could outline what your mission is here, what the constraints are, what the goals are, how you intend to contribute this back to Deltaspike, what your timeline is etc that would help.

I think Deltaspike does a good job of outlining it's plans for security on the wiki page. As mentioned before, if there aren't requirements that are being met that you require, please add them.

[Jay Balunas]

On Wednesday, May 9, 2012 9:53:05 AM UTC-4, Pete wrote:

I would suggest that rather than starting with the question "how do I abstract this out", we instead discuss what you want to achieve.  

If you start a conversation half way through, based on premises that you know there are strong objections to, don't be surprised that people react badly.

For example, perhaps you could outline what your mission is here, what the constraints are, what the goals are, how you intend to contribute this back to Deltaspike, what your timeline is etc that would help.

I think Bruno's already done a pretty good job covering most of that in the readme.md, and security.md files he links to below.  

As for how to contribute back to Deltaspike that is something we want to discuss, and Bruno's already been pretty involved in the DeltaSpike mailing list.  He is planning on reviewing this with Shane and others, as well as aspects like the authentication API (mentioned below) to get some advice.

The timeline is completely in the air as we are just in PoC stage.  A lot will depend on how these other discussions go, and is tbd.

[Lincoln Baxter, III]

Hey Bruno,

Did you look at the integration work that I did using Rewrite? What are your thoughts?

More responses inline.

On Tue, May 8, 2012 at 4:22 PM, Bruno Oliveira <br...@abstractj.org> wrote:

Hi folks, I had some few simple ideas on aerogear security and I want to share them. 

I did some replacements with CDI interceptors to get rid of all Resteasy dependencies, because it was a lightweight way to integrate with aerogear controller (inspired on SecurityInterceptor from DeltaSpike) and started to write users/roles permissions (it's really simple)

I have some thoughts about this. Rewrite can be used to define these also; I will play around that as well, but I'd like to hear your thoughts on the above before I begin.

~Lincoln

[Bruno Oliveira]

Hi not really, I was chatting with Pete and Jason about replace all the stuff that I did on aerogear-controller-demo with DeltaSpike Security. I believe that's the way to go.

Does Rewrite is currently part of DeltaSpike? I would like to keep only DeltaSpike in this demo.

But thanks for the tip.

[Lincoln Baxter, III]

Hey Bruno,

Rewrite is a separate concern from DeltaSpike. It's not related to CDI or security, but is a powerful framework to provide "glue." It does not appear in client APIs, and will not introduce coupling for end users. It's purely something I am suggesting to keep the code simpler and prevent re-inventing things that have already been done, while at the same time allowing for a lot of flexibility in the future without needing to modify architecture of the framework. It's also a project that I lead, so if we need features added to it, it's something we can do.

Please take a look at my pull request and let me know what you think. It's big, but it should be clear what was done and won't take long to grok.

Thanks,
Lincoln

[Shane Bryzak]

I'm coming in a bit late on this, however most of the points that I was going to make have already been made by other people.  One thing I'd like to reinforce (and was mentioned by Pete) is that DeltaSpike provides a security API, with a few implementations to support common security use cases.  Every aspect of the security module is designed to be pluggable and extendable, so if there's a use case that we're not supporting with the API then we need to be told about it.  The specific document that we're working off (and which contains all of our current use cases) for the security module design is here:

https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts

Feel free to add to this document any use cases that we've missed, or let me know and I'll add them for you.

[Lincoln Baxter, III]

Woops. I just realised that I had you and Douglas confused! Sorry! I should be asking him this :) but I guess you can might still have comments if you are also working on the MVC PoC.

My bad,
Lincoln