SOA should tell me what these are ASAP.
What we are going to do for WildFly 8 is very limited though and it's
not likely to expand much.
On 5/9/13 3:37 PM, Alan Santos wrote:
On May 9, 2013, at 4:31 PM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> I'd say !@#$%
I had a similar response when I saw RBAC on such a short runway :)
>
> I'd also say I'm interested to hear more, but the schedule we are
> working on is very tight and the first iteration is going to target a
> pretty specific set of use cases.
>
> The feature is related to server/domain administrative security, not
> application security. I understand that's a bit blurry when the
> application is doing server/domain administration.
>
Since the 'application' John is referring to is RHQ those use-cases you're
targeting are pretty much a subset of what he has in mind (at the risk of putting words in
his mouth, though that's never stopped me before).
I had similar questions for other layered products - if, say, SOA, had some
administrative concepts or roles that weren't present in EAP then should that product
be expected to take advantage of RBAC or does it need to provide an additional RBAC
mechanism?
>
> On 5/9/13 3:21 PM, John Mazzitelli wrote:
>>> a number of our EAP
>>> customers have requested that we add Role/Resource Based Access Control into
>>> a future EAP 6.x release.
>>
>> What would you say if someone asked you to try to make this new RBAC feature
generic/extensible such that applications/layered products could plug into it and use it
for their own authorization purposes? Not only to allow to hook into the roles, but also
be able to attach custom external (app-specific) entities to the roles so third party apps
could use the roles and attach their own concept of "resources" or other
entities to the roles?
>>
>> I'm looking for an answer other than !@#$% ;) (sorry, couldn't resist)
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev