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>
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.
- OAuth: The winner, but we still must start the implementation.
* Client library support
* Where does Crypto.SHA1 come from
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.
* 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
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
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?
ok - this might be where I need to review more. Its been too long.
"Know the rules well, so you can break them effectively" - Dalai Lama XIV
Volenti Nihil Difficile