Should the auth realm for admin be dynamic?

View: New views
3 Messages — Rating Filter:   Alert me  

Should the auth realm for admin be dynamic?

by vince kraemer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I am working on
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10512 and haven't
found a way to squash it yet....

but, I am also left with this unanswered question... Do we really want
to change the authentication mechanism for admin privileges dynamically?

Note: the reason that it appears to be dynamic for the filer is due to
the fact that their domain is initializing lazily... and the security
service has not initialized before a call to config-ldap-for-admin.

Since there is a work-around... restart the domain after calling
config-ldap-for-admin, I am also tempted to lower this issue to p4.

Thanks,
vbk




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: Should the auth realm for admin be dynamic?

by llc :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Seems like a low priority to be able to change the admin domain  
dynamically.

On Oct 29, 2009, at 4:34 PM, Vince Kraemer wrote:

> I am working on https://glassfish.dev.java.net/issues/show_bug.cgi?id=10512 
>  and haven't found a way to squash it yet....
>
> but, I am also left with this unanswered question... Do we really  
> want to change the authentication mechanism for admin privileges  
> dynamically?
>
> Note: the reason that it appears to be dynamic for the filer is due  
> to the fact that their domain is initializing lazily... and the  
> security service has not initialized before a call to config-ldap-
> for-admin.
>
> Since there is a work-around... restart the domain after calling  
> config-ldap-for-admin, I am also tempted to lower this issue to p4.
>
> Thanks,
> vbk
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Lloyd Chambers
lloyd.chambers@...
GlassFish Team




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: Should the auth realm for admin be dynamic?

by Bill Shannon :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

FYI, note that changes such as this are problematic for the
restart-domain command.  restart-domain issues commands to the
server to watch for the server to restart.  If the authentication
required to execute these commands changes when the server restarts,
restart-domain has no way to know that, nor does it have any way to
allow you to specify the credentials to be used after restart.

I think this is only a minor issue, but I wanted to point it out...


Lloyd Chambers wrote on 10/30/09 07:13:

> Seems like a low priority to be able to change the admin domain
> dynamically.
>
> On Oct 29, 2009, at 4:34 PM, Vince Kraemer wrote:
>
>> I am working on
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=10512 and
>> haven't found a way to squash it yet....
>>
>> but, I am also left with this unanswered question... Do we really want
>> to change the authentication mechanism for admin privileges dynamically?
>>
>> Note: the reason that it appears to be dynamic for the filer is due to
>> the fact that their domain is initializing lazily... and the security
>> service has not initialized before a call to config-ldap-for-admin.
>>
>> Since there is a work-around... restart the domain after calling
>> config-ldap-for-admin, I am also tempted to lower this issue to p4.
>>
>> Thanks,
>> vbk
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> Lloyd Chambers
> lloyd.chambers@...
> GlassFish Team
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...