[wildfly-dev] WildFly 8 Schedule

[Alan Santos]

On May 9, 2013, at 4:31 PM, Brian Stansberry <brian.stansberry at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev