[wildfly-dev] inheriting security domain

[Jason T. Greene]

I see your point, but I have to agree with Bill that it's not what a user expects. We should let DUPs push/pop the specified domain in an attachment.

Sent from my iPhone

> On Mar 12, 2014, at 2:40 PM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
> 
> It is subjective about assuming reasonable defaults.
> 
> In the case of EARs, historically, we used the security domain
> at the EAR level for all the containing web,ejbs that were missing 
> explicit security domains.
> 
> A security domain is an abstract concept to define boundaries for 
> authentication, authorization, mapping,audit etc.
> So a web app may use different security domain compared to an EJB 
> application.
> 
> In the case of web archives containing EJB applications, the options are:
> a) Make the EJB define the security domain explicitly to be the one used 
> by the web app.
> b) Make the EJB inherit the security domain used by the web app if missing.
> c) Make the EJB default to "other" if a security domain is missing.
> 
> If we go with c) like it is now, a developer can test his application 
> and see that his EJB application is not working
> as he intends. Then he can either opt for a) or leave it as c)
> 
> The danger with option b) is if someone put the war in production and 
> the EJB application does not 'fail fast'.
> 
> But if people on this list feel that b) is the better usable solution, 
> then we should go for it.
> 
>> On 03/12/2014 08:16 AM, Bill Burke wrote:
>> I noticed that if you define a WAR's security domain and then define an
>> EJB within WEB-INF/classes, that EJB's default security domain is
>> "other" and not the WAR's security domain.
>> 
>> Don't you think it would be more user friendly and intuitive for nested
>> components' security domain to be inherited from their parent container
>> rather than defaulting to "other"?
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev