[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Aerogear-dev] Feedback on security readme

On Mar 29, 2012, at 1:17 PM, Bruno Oliveira wrote:

Jay, just quick considerations

- crypto-js api I just sent a e-mail to the owner about move it to github, without answer. The project is licensed under BSD (http://www.opensource.org/licenses/bsd-license.php), I think we can use it.


- crypto-js is not a standard, but I'm comfortable with it 'cause SHA-1 algorithm is.

Is the community active, i.e. if we find a problem is there a "community" there to work with?

- about user.properties was just to test our authentication flow and it's totally **unsafe**, for this reason my initial suggestion is to use JAAS integrated with databases on the servers side, configured at standalone.xml. But of course that we can study a alternative to keep it on application layer.

I'm sure there will have to be a container lvl involvement to get good security, the trick to me is how much?  And how can we hide as much as possible so app developers are dealing at a higher lvl.

Good stuff though - keep it up!

- Bruno

On Thu, Mar 29, 2012 at 1:54 PM, Jay Balunas <jbalunas redhat com> wrote:

On Mar 29, 2012, at 10:41 AM, Bruno Oliveira wrote:

I'll assume that HTTPS will be used overall mobile ecosystem.


How will this effect our demo's - we'll need to use an invalid cert right?  Or just provide instructions for updating it to SSL

Let me know if something is not really clear.

On Thu, Mar 29, 2012 at 9:58 AM, Jay Balunas <jbalunas redhat com> wrote:

Overall great stuff.  Note, some of the items are questions from me, and some are questions I could see being asked by others :-)

* HTTP Digest authentication - why this?  What alternatives exist

The alternatives are: Basic (clear text), Digest (SHA1), WSSE, OAuth (to be discussed)    
- Basic: The credentials will be sent in plain text, encrypt each HTTP transaction over SSL don't guarantee the protect the information integrity when the information arrives to the server from internal network snoops.  

Fair point - about integrity even at the server.

- Digest: Using SHA1 in combination with username + password + random + other information (to be discussed) that we could choose is safer than basic imo, the client won't send your information, but a combination. Signed URIs will be helpful to the next steps.

- WSSE: it's XML, enough to be excluded :) http://www.xml.com/pub/a/2003/12/17/dive.html.

- OAuth: The winner, but we still must start the implementation.


* Client library support 
* Where does Crypto.SHA1 come from 
 * should list that

ok I saw this when I did a quick search, but wanted to make sure.  Is this considered a defacto-standard?  and how is the licensing for including in our stuff?

* We will want to collapse JS into mini-lib imo

+1 about have JS libs.

 * Not relative path? 
 * can be point to other places?
Sure thing, it's just an example to test Authentication process. The requests will be intercepted and resources with @Secured annotation will be authenticated. 


* phase 1
  * authorization only right
authentication I guess)

Yup - typo

  * Can you use CDI to inject a user object?
    * for further work.

I would like to understand your idea before. It's possible inject a user object, but I would like to think about how to integrate it with controller or expose authentication resources (Technically is possible we're already using CDI here) 

Right so here you want to be able to inject the current User like this

User user;

user.isInGroup (eventually)

But the trick here is getting into specifics, and I'm not sure how JAAS or Seam security handle it.

* Web mobile --> web/mobile 


* Define the domain a little better

Means security-domain, the idea is to use JBoss for it https://community.jboss.org/wiki/JBossAS7SecurityDomainModel 

I hate the container based domain models and user.properties, and role.properties.  Myself and some others refer to this as container security.  Its fine if you are thinking at the container level.  I personally prefer to think at the application layer.  Think PaaS, and self contained apps.  I can't image someone at github updating the user.properies when someone registers ;-)

I see how we could use it for initial authentication, but for authorization we need something easier, and hopefully declaritive.  Did you see all that xml :-(

This is the type of thing that should be hidden from the developers if at all possible.  We would need an abstraction layer (perhaps aerogear-sec, DS) that handles things are a application level.  Checking a DB, LDAP, etc.. behind the scenes. This would then be extended to support application level groups/roles/factions.

* does getUser return a user object, or a Long?

getUser was a bad example and isn't related with aerogear security implementation. Replacing it with lookupMemberById.


* What happens when the you access secured resources and you're not logged inject

If we have plans to move forward with aerogear-security ideas, probably exception mapper must be implemented with resteasy.


* Where and how are users created, edited, removed?

Users/groups will be created using database integrated service with AS with JAAS (https://docs.jboss.org/author/display/AS7/Security+subsystem+configuration)

ok - this might be where I need to review more.  Its been too long. 

Let me know if you have more concerns.


aerogear-dev mailing list
aerogear-dev redhat com

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]