This sounds reasonable to me as well.
On Jul 27, 2012, at 1:10 AM, Shane Bryzak sbry...@redhat.com wrote:
I had a quick chat with Pete and Jason and they brought me up to speed.
After much consideration I think the best way to proceed would be 4.b), with
the more complex features such as
On Jul 9, 2012, at 2:50 AM, Shane Bryzak wrote:
As far as Identity Management related features are concerned, I've
purposefully kept that separate except for the minimal overlap in the
identity model classes. Bolek is holding the reigns for IDM and I'm certain
we'll be discussing it in
Porter lightguard...@gmail.comwrote:
I have some stuff I did on the plane from Summit. I'm going to go back
over it tomorrow and see if I included everything I wanted. I'll send the
diff to the list.
Sent from my iPhone
On Jul 1, 2012, at 9:43, Boleslaw Dawidowicz
boleslaw.dawidow
I think there will be few more frameworks to integrate with. JSR 351 is another
example of something that should be consumed.
Bolek
On Jul 9, 2012, at 9:29 AM, Romain Manni-Bucau wrote:
well, why i asked was to get started with shiro is 5mn, to get started
with current security module is a
JSR 351 was mentioned few times in previous discussions as something that we
should keep an eye on. Therefore I would like to let you know that source code
repository related to this effort is now public.
Here is the API draft:
http://java.net/projects/identity-api-spec/sources/git/show
Here
I think it all comes down (again) to use cases [0] which we think this API
should address. Current ones are mainly around typical web application
development and proposed API prototype was focusing on easy usage. My main fear
is to go end up with too abstract and generic design that won't be
Hello,
so late introduction from myself :)
I live in Poland - Warsaw area - and work remotely from there. On the
professional side since quite a few years focused on JEE portals. Currently I'm
the GateIn Portal Project Lead [0] and Platform Architect of corresponding
RedHat product offering
On Apr 25, 2012, at 12:52 AM, Marek Posolda wrote:
Based on your last mail with subject [DISCUSS] DELTASPIKE-79 Authorization
API - Identity Model I assume that best case would be to cover
IdentityType in the API, which will allow possibility to cover
users/groups/roles. So having method
As we are starting discussion around Identity Model for Authorization API I
would like to also open one around Identity Management APIs. I was working on
some prototype based on previous experience with PicketLink IDM API. Here is
the code that is a reference to what I'm proposing in this
I started separate thread about Identity Management API today. However as
Gerard pointed on IRC it may be wiser to not keep 4 different threads running
in parallel around similar domain.
I think pretty everything that Shane suggested here around IdentityType, User,
Group and Role is in line
On Apr 24, 2012, at 2:41 PM, Shane Bryzak wrote:
2) How about cover user identity in the API? For example: I want to know
that user john has permission to READ customer Mary Kelly. With current
API I would need to call: listPermissions(maryKellyCustomer, READ) and
then iterate through
On Apr 24, 2012, at 2:59 PM, Marek Posolda wrote:
On 24.4.2012 14:41, Shane Bryzak wrote:
On 24/04/12 18:56, Marek Posolda wrote:
Hi Shane,
If I understand correctly this PermissionManager would be used by
PersistentPermissionResolver, which will be the default PermissionResolver
On Apr 24, 2012, at 3:17 PM, Boleslaw Dawidowicz wrote:
On Apr 24, 2012, at 2:59 PM, Marek Posolda wrote:
On 24.4.2012 14:41, Shane Bryzak wrote:
On 24/04/12 18:56, Marek Posolda wrote:
Hi Shane,
If I understand correctly this PermissionManager would be used
+1 (non binding)
Bolek
On Apr 15, 2012, at 10:30 PM, Mark Struberg wrote:
Hi folks, I'd like to call a VOTE on releasing Apache DeltaSpike
0.2-incubating. The Maven staging repository:
https://repository.apache.org/content/repositories/orgapachedeltaspike-051/
Source release:
be performed all in one class.
On 02/03/12 06:41, Boleslaw Dawidowicz wrote:
On Feb 29, 2012, at 10:25 PM, Shane Bryzak wrote:
currently i'm thinking about the dis-/advantages of moving those methods to
User (or something like AuthenticatedUser)
I think this would create complications when we
On Feb 29, 2012, at 10:25 PM, Shane Bryzak wrote:
currently i'm thinking about the dis-/advantages of moving those methods to
User (or something like AuthenticatedUser)
I think this would create complications when we start getting into the
Identity Management API. The User object is
On Feb 12, 2012, at 11:33 PM, Shane Bryzak wrote:
Some particular points to review:
1. Should we attempt to use the security classes provided by Java SE, such as
Principal, Subject, etc or use our own User API - this will affect what is
returned by the getUser() method above. Keep in
17 matches
Mail list logo
