The Oracle XMLDB “anonymous” user account

Trying here to be as correct as possible, as far as I understand it currently.

ANONYMOUS is an Oracle user account specifically designed for HTTP access. It has only one system privilege, that is “create session” and the account is locked by default. If it is unlocked, it only is used for HTTP access via the XDB Protocol Server, aka PL/SQL Gateway, and can access objects in the XDB Repository that are protected by an ACL (Access Control Lists) mentioning this “principal”.

By default there is no ACL file that grants any privilege to this “user” ANONYMOUS. When APEX is installed then there will be a /sys/acls/ro_anonymous_acl.xml file that grants read access to the /images/ or /i/ directory (depending on the APEX version). If you lock ANONYMOUS or remove the ACL defined privileges then APEX can not show/access those files in that XDB Repository folder (/images, /i) if you would need to access these files. For example when using the APEX listener setup the application images and help doc images are stored locally on the server and not in the database, so in principal there is no need to access those image(s) directories in the database.

Example of an ACL which can used by XDB which grants read properties and read content rights to all objects which are protected by this ACL

  
    ANONYMOUS
    true
    
      
      
      
    
  

By default when a resource (a file or folder) is created by a process it will get the privileges defined in the bootstrap ACL (which is protected by itself). So no privileges will be granted to this ANONYMOUS account by default. And even when unlocked, this user only opens up, by default, to hierarchy enabled, XDB Repository related objects. Mind the mentioning “by default”; Its is possible to opening up and overrule default security ruling in place when you alter the content of ACL defaults (which is, could be considered, a security breach). For example you could alter the contents of the bootstrap_acl.xml file in such a way, if your have maliceious intentions from within the database, but you would need very powerful database account access to start with anyway, to make this happen.

Example of the default content of the bootstrap_acl.xml file:

SQL> select xdburitype('/sys/acls/bootstrap_acl.xml').getCLOB() from dual;
 

  
    dav:owner
    true
    
      
    
  
  
    XDBADMIN
    true
    
      
    
  
  
    PUBLIC
    true
    
      
      
      
      
    
  

Be aware that, although the PUBLIC ACE (Access Control Entries) entry sounds dangerous, this only means that from within the database DIRECT access to the objects via database accounts are possible. This is not possible via HTTP (by default). An example to this effect would be that for the APEX /images directory, which is protected only for read only access of the principal ANONYMOUS, this means that PL/SQL packages (owned/executed by users from WITHIN the database) etc, will not have access to these image files.

The “service” provided via the XDB Protocol Server and its access rules are defined in the xdbconfig.xml configuration file. The services defined there (for example APEX’s entries via PL/SQL, that is, via the PL/SQL gateway) in this xdbconfig.xml file links up to the to be used “principal” (ANONYMOUS in the case of APEX) security access owner, role, trusted user or LDAP definition, for that specific service.

Normally an anonymous user is a user whose credentials have not been validated (hence unauthenticated) that is permitted access to only unprotected resources, but by default all created objects in the XDB repository will be protected by the default bootstrap ACL and in normal cases a ACL with a defined ANONYMOUS principal is not created, does not exist in the database. Even if, you would still need entries in the xdbconfig.xml file that link the (unlocked) ANONYMOUS account with a defined service that grants you access or an entry point to the database.

The underlying by Oracle implemented security mechanism is the same as for the database and also it used the advanced security feature VPD. Due to the fact that Oracle itself makes use of this, a extra license is not needed for this advanced security feature, as long as you don’t use it yourself. Oracle XMLDB in itself is a “no cost option” that comes along when you buy the licenses needed for your database software.

This is a backup copy of a XMLDB OTN Forum Thread.