directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: Audit Entries
Date Tue, 22 Nov 2016 10:42:05 GMT
Hi Chis,

a very good question and yes you are correct, the reqauthzid is mapped to the connection pool's
ldap userid.

Of course this isn’t really helpful if you’re trying to figure out who the end user was
doing the admin functions.  For that we must understand how fortress stores its administrative
contextual info so we must have a look at one of the aux obj classes:

## AC4: Fortress Audit Modification Auxiliary Object Class
objectclass ( ftAxId:4
    NAME 'ftMods'
    DESC 'Fortress Modifiers AUX Object Class'
    AUXILIARY
    MAY (
        ftModifier $
        ftModCode $
        ftModId
        )
   )

which can be attached to ldap mods automatically whenever audit has been enabled in the fortress
properties.  It uses data contained from within its base logical entity:

public abstract class FortEntity
{
    protected String modCode;
    protected String modId;
    @XmlTransient
    protected Session adminSession;
    protected long sequenceId;
    @XmlTransient
    protected String contextId;

One trick: The internal userid is mapped to ftModifier attribute instead of external one.
 (something that should perhaps be discussed further)

A screenshot on slide #40 shows the raw ldap audit data mappings: 
http://schd.ws/hosted_files/apacheconeu2016/db/Apache-Fortress-ACEU-2016-v2.pdf

and here is the data provider’s method that sets the values onto the ldap entry:

public abstract class LdapDataProvider
{
...
    /**
     * Add the audit context variables to the modfication set.
     *
     * @param mods   used to update ldap attributes.
     * @param entity contains audit context.
     */
    private void audit( List<Modification> mods, FortEntity entity )
    {
        if ( !Config.getInstance().isAuditDisabled() && ( entity != null ) &&
( entity.getAdminSession() != null ) )
        {
            if ( StringUtils.isNotEmpty( entity.getAdminSession().getInternalUserId() ) )
            {
                Modification modification = new DefaultModification( ModificationOperation.REPLACE_ATTRIBUTE,
                    GlobalIds.FT_MODIFIER, entity.getAdminSession().getInternalUserId() );
                mods.add( modification );
            }

            if ( StringUtils.isNotEmpty( entity.getModCode() ) )
            {
                Modification modification = new DefaultModification( ModificationOperation.REPLACE_ATTRIBUTE,
                    GlobalIds.FT_MODIFIER_CODE, entity.getModCode() );
                mods.add( modification );
            }

            if ( StringUtils.isNotEmpty( entity.getModId() ) )
            {
                Modification modification = new DefaultModification( ModificationOperation.REPLACE_ATTRIBUTE,
                    GlobalIds.FT_MODIFIER_ID, entity.getModId() );
                mods.add( modification );
            }
        }
    }


But this is all really complex right?  So to simplify these searches for the end user we have
the auditmgr funcs:


public interface AuditMgr extends Manageable
{
    /**
     * This method returns a list of admin operations events for a particular entity 
     * {@link org.apache.directory.fortress.core.model.UserAudit#dn},
     * object {@link UserAudit#objName} and timestamp {@link org.apache.directory.fortress.core.model.UserAudit#beginDate}.
 
     * If the internal userId {@link org.apache.directory.fortress.core.model.UserAudit#internalUserId}
is set it will limit 
     * search by that field.
     * <h3></h3>
     * <h4>optional parameters</h4>
     * <ul>
     *   <li>
     *     {@link UserAudit#dn} - contains the LDAP distinguished name for the updated object.
 For example if caller
     *     wants to find out what changes were made to John Doe's user object this would be

     *     'uid=jdoe,ou=People,dc=example,dc=com'
     *   </li>
     *   <li>
     *     {@link UserAudit#objName} - contains the object (authorization resource) name corresponding
to the event.  For 
     *     example if caller wants to return events where User object was modified, this would
be 'updateUser'
     *   </li>
     *   <li
     *     >{@link org.apache.directory.fortress.core.model.UserAudit#internalUserId} -
maps to the internalUserId of user 
     *     who changed the record in LDAP.  This maps to {@link org.apache.directory.fortress.core.model.User#internalId}.
     *   </li>
     *   <li>{@link UserAudit#beginDate} - contains the date in which to begin search</li>
     *   <li>{@link UserAudit#endDate} - contains the date in which to end search</li>
     * </ul>
     *
     * @param uAudit This entity is instantiated and populated before invocation.
     * @return a List of objects of type Mod.  Each Mod object in list corresponds to one
update or delete event on directory.
     * @throws SecurityException
     *          if a runtime system error occurs.
     */
    List<Mod> searchAdminMods( UserAudit uAudit )
        throws SecurityException;


Thanks,
Shawn


> On Nov 21, 2016, at 8:39 AM, Chris Pike <clp207@psu.edu> wrote:
> 
> Looking at the OpenLdap Audit logs. In our setup, it looks like the reqAuthzId will always
be the same user used to connect to the server, is there a way to log the user set in the
admin session on the manager?


Mime
View raw message