inheriting security domain

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

inheriting security domain

Bill Burke
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"?


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: inheriting security domain

Anil Saldhana
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev