[wildfly-dev] inheriting security domain

[Anil Saldhana]

https://issues.jboss.org/browse/WFLY-3122

On 03/12/2014 11:20 AM, Jason T. Greene wrote:
> 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"?
>>