Looking at the problem a bit more closely, there can be some nasty subtleties depending on what you are actually trying to secure. If you haven't already done so, you should read the recent thread in this [ed: comp.object.corba] group titled "Naming Service and SSL".
It is fair enough to want only "authorized clients" to write to a naming service, but (potentially) any object that wishes to export its object reference to a name server has to have some write permission, and also the permission to remove its own reference. It may be possible to give everyone the ability to export objrefs, but only privileged clients power to change the structure of the namespace - I'm affraid I don't know the name server interface well enough to say, but CORBA Security is capable of distinguishing different operations on an interface.
There can be bootstrap problems with secure name services in some CORBA Security systems. But these occur when you want to treat the name service as a source of TRUSTWORTHY object references. Basically, to bootstrap CORBA Security you may need to obtain some trustworthy object references (for example of Authentication and Privilege services) BEFORE you can talk securely to anyone, including the name service. I believe this situation is different for simple public key based systems (such as CORBA SSL) that can bootstrap without external object support.
The subtlety in the other thread is a consequence of the fact that CORBA Security does not guarantee that the security name embedded in an object reference is the CORRECT security name. Just because you secure access to the name server does not necessarily mean that clients are not exporting object references with false information in them. Changing the security name in an objref would allow an attacker to masquerade as the genuine object, even though the security service is active (including the EstablishTrustInTarget feature!).
To overcome this with a secure name service, you would need very application/system specific access controls (that look at message content) or you would have to trust your (exporting) clients. CORBA Security (appendix D.6.2 of the latest specification) says that end users (clients) of object references are responsible for verifying their security names unless they have a trusted source of objrefs. I'm just pointing out that putting access control and message protection on a name server doesn't necessarily provide a trusted source of objref CONTENTS.
It is sometimes perfectly possible for clients to know and check the security names of objects. For example in DAIS Security the bootstrap problem mentioned above is avoided because the authentication client can predict the correct security name of the appropriate Authentication and Privilege services for its particular domain. However, in general, it is very difficult for clients to know the correct name - and in the case of security UNAWARE applications they are not supposed to know anything about security anyway! This is also discussed (and solutions proposed) in the other thread.