nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dynamic AliasSet creation - what is the downside?

ndegroff

To all concerned,

In a previous thread (https://community.emc.com/message/754423) PanfilovAB provided a great solution to address a unique business requirement

The requirement is to prevent a specific user from viewing a document if the document is about themselves.

The solution entails using a TBO to apply an AliasSet to a templated ACL to dynamically set an AccessRestriction rule. However, the solution requires one AliasSet to be created per user. This involves a good deal of maintainence as in this case thousands of users will be added during the course of a year with an initial user base of 50,000 users.

I believe it would be possible to dynamically create an AliasSet every time a doSave() event is triggered just to set the user name on the ACL template. What would be the downside to doing the following:


    @Override
    protected synchronized void doSave( boolean saveLock, String versionLabel, Object[] extendedArgs )
            throws DfException
        {
        //-----------------------------------------------------
        // Get Session information
        IDfSession idfSess      = getSession();
        String strTStamp        = timeStamp();              // some custom unique timestamp string
        String strAliasSetOrig  = idfSess.getAliasSet();
        //-----------------------------------------------------
        // Create new Alias Set on fly
        IDfAliasSet idfAliasSet = (IDfAliasSet) idfSess.newObject("dm_alias_set");
        idfAliasSet.setString( "owner_name", "dm_dbo" );
        idfAliasSet.setObjectName( strTStamp );
        idfAliasSet.appendAlias( "related_to",  // String name
                "username",                     // String value
                IDfAliasSet.CATETORY_USER,      // int category
                0,                              // int userCategory
                "Temporary User Name" );        // String description               
        idfAliasSet.save();
        //-----------------------------------------------------
        // Set Session Alias Set to the new Alias Set
        idfSess.setAliasSet( strTStamp );
        //-----------------------------------------------------
        // Apply ACL Template
        this.setACLDomain( "dm_dbo" );
        this.setACLName( strACL );
        //-----------------------------------------------------
        // Invoke Super Save
        super.doSave( saveLock, versionLabel, extendedArgs );
        //-----------------------------------------------------
        // Set Session Alias Set back to original
        idfSess.setAliasSet( strAliasSetOrig );
        //-----------------------------------------------------
        // Destroy temporary Alias Set
        idfAliasSet.destroy();    
        }

Find more posts tagged with

Comments

ndegroff

After some digging, I think I found the answer. I can't destroy the Alias Set once I've created an ACL that refers to it. The ACL created using the ACL Template now has two links;

r_template_id - this refers to the r_object_id of the ACL Template used.
r_alias_set_id - this refers to the Alias Set that resolves all of the user / group references in the ACL template

If i change the value in the Alias Set or the orignal ACL template, these references will ensure that the changes will reflect in all ACLs linked to these values. I bet if I were to delete an Alias Set, it would complain saying there are links already in place.

I'm going to try a different tack. Rather than creating a "dynamic" Alias Set, i'm going to check to see if said Alias Set exists. If it does not, i will create a new alias set for that user. If it already exists, it can pull the existing set.

At least in this regard, we won't have to remember to create an Alias Set when we provision new users. It will dynamically get created if one does not already exist.

I'll keep this thread open for a while as i test this theory out. Feel free to comment should you so choose.

PanfilovAB

If you are using some special attribute for storing target security user, you can use code like:


@Override
protected final void doSave(final boolean keepLock,
        final String versionLabels, final Object[] extendedArgs)
    throws DfException {
    new TransactionalFunctorWithRetry(getObjectSession(), new Functor() {
        @Override
        public Object evaluate() throws DfException {
            doSaveImpl(keepLock, versionLabels, extendedArgs);
            return null;
        }
    }, true).evaluate();
}

protected void doSaveImpl(final boolean keepLock,
        final String versionLabels, final Object[] extendedArgs)
    throws DfException {
    String targetUserAttribute = "user_arrtribute";
    if (isStringAttrChanged(targetUserAttribute)) {
        setAliasSetId(getSecurityAliasSet(getString(targetUserAttribute))
                .getObjectId());
        setACLName("my_acl_template");
        setACLDomain("acl_owner");
    }
    super.doSave(keepLock, versionLabels, extendedArgs);
}

protected IDfAliasSet getSecurityAliasSet(String userName)
    throws DfException {
    if (userName == null || userName.trim().length() == 0) {
        return getDefaultSecurityAliasSet();
    }

    String aliasSetName = "security_alias_set_for_" + userName;

    IDfAliasSet aliasSet = (IDfAliasSet) getObjectSession()
            .getObjectByQualification(
                    "dm_alias_set where object_name='"
                            + DfUtil.escapeQuotedString(aliasSetName ) + "'");

    if (aliasSet == null) {
        aliasSet = (IDfAliasSet) getObjectSession().newObject("dm_alias_set");
        aliasSet.setObjectName(aliasSetName);
        aliasSet.setOwnerName(getObjectSession().getDocbaseOwnerName());
        aliasSet.appendAlias("related_to", userName,
                IDfAliasSet.CATETORY_USER, 0, null);
        aliasSet.save();
    }
    return aliasSet;
}

protected IDfAliasSet getDefaultSecurityAliasSet() throws DfException {
    IDfAliasSet aliasSet = (IDfAliasSet) getSession().getObjectByQualification(
            "dm_alias_set where object_name='default_security_alias_set'");
    if (aliasSet == null) {
        aliasSet = (IDfAliasSet) getObjectSession().newObject("dm_alias_set");
        aliasSet.setObjectName("default_security_alias_set");
        aliasSet.setOwnerName(getObjectSession().getDocbaseOwnerName());
        aliasSet.appendAlias("related_to", getObjectSession().getDocbaseOwnerName(),
                IDfAliasSet.CATETORY_USER, 0, null);
        aliasSet.save();
    }
    return aliasSet;
}


protected boolean isStringAttrChanged(String attrName) throws DfException {
    if (isNew()) {
        return true;
    }

    IDfSysObject uncachedObject = (IDfSysObject) getObjectSession()
            .getUncachedObject(getObjectId(), null);

    String currentValue = getString(attrName);
    String oldValue = uncachedObject.getString(attrName);

    return !((currentValue == oldValue)
            || ((currentValue != null) && (oldValue != null) && currentValue
                    .equals(oldValue)));
}

Note, doCheckin() method should be overridden too.

PanfilovAB

Forgot important aliases part:


public void setAliasSet(String aliasSet) throws DfException {
    IDfAliasSet aliasSetObj = (IDfAliasSet) getSession()
            .getObjectByQualification(
                    "dm_alias_set where object_name='"
                            + DfUtil.escapeQuotedString(aliasSet) + "'");
    if (aliasSetObj == null) {
        throw new DfException("Unable to find alias set with object_name: "
                + aliasSet);
    }
    setAliasSetId(aliasSetObj.getObjectId());
}

public void setAliasSetId(IDfId aliasSetId) throws DfException {
    setIdInternal("r_alias_set_id", aliasSetId);
}

ndegroff

The one thing about creating a dynamic Alias Set on the fly is that only SuperUsers can do this. I tried creating an AliasSet with a generic user and it failed. If I embedded it in TBO logic, it would fail if a generic user hit that segment of code.

PanfilovAB

The one thing about creating a dynamic Alias Set on the fly is that only SuperUsers can do this.  I tried creating an AliasSet with a generic user and it failed.

Could you post the error you got? It's very strange, because any user s able to create aliases.

ndegroff

Here's a run with generic user


API> create,c,dm_alias_set
...
66------80000dd3
API> set,c,l,object_name
SET> test_security_nate_alias
...
OK
API> set,c,l,owner_name
SET> dm_dbo
...
OK
API> append,c,l,alias_name
SET> related_to
...
OK
API> set,c,l,alias_value
SET> some_usr
...
OK
API> save,c,l
...
Cannot change the owner name of the test_security_nate_alias alias set.
Invalid handle (66------80000dd3) for system event dm_security_check_failed.

Here's the same run as a super user


API> create,c,dm_alias_set
...
66------80000ddc
API> set,c,l,object_name
SET> test_security_nate_alias
...
OK
API> set,c,l,owner_name
SET> dm_dbo
...
OK
API> append,c,l,alias_name
SET> related_to
...
OK
API> set,c,l,alias_value
SET> some_usr
...
OK
API> save,c,l
...
OK

PanfilovAB

I can't find any reason why you're trying to set dm_dbo as aliasset owner

ndegroff

I may be a little rusty, but isn't


API> set,c,l,owner_name
SET> dm_dbo

in API

the same thing as your java call:


aliasSet.setOwnerName(getObjectSession().getDocbaseOwnerName());

?
They both set the owner of the alias set to the docbase owner.

PanfilovAB


They both set the owner of the alias set to the docbase owner.

Correct, but I just copied it from your:


idfAliasSet.setString( "owner_name", "dm_dbo" );

Actually I was wrong in previous post, and It's a proper direction to set owner_name of aliasset to dm_dbo, because it introduces additional security, but such implementation requires either privilege escalation during creation of aliasset or additional maintenance of aliassets as was mentioned in our previous discussion.

Alternative point is: I'm sure that user, that creates such documents, is securing it against another user, so there is no security issue if you leave current user as aliasset owner.

Jeremy Saumen

Hi,

We are using a similar approach to set the security on our client's document but to create the alias sets we are using a dm_method. This allows us to create/update the alias sets automatically thanks to the schedule of a dm_job and the dm_method can also be called through the TBO with a non-mandatory attribute (specifying the client) to create a specific alias set. As the dm_method runs on the JMS, you can use the user that suits you the best ; in my case it's the installation owner.

PanfilovAB

I always hate privilege escalation by executing method - it requires running JMS, but until d6 that was the only way. But in this case it can be implemented by the following way: create insecure aliasset in TBO, and then using job secure it by changing owner_name.

ndegroff

Jeremy and Panfilov,

Thanks to you both for your comments. Jeremy, I used to invoke dm_methods on the server back in the 5.2.5 days via TBOs. Initially, it was great. If the object was protected from activity by ACL and the business process needed to flip a date or update something the current user session didn't have privs for, I could accomplish that for free and not have to store super user credentials.

Why Method Server failed to handle Super User transactions invoked from TBO

However, I found that the method server would, from time to time, fail for one reason or another. Since key pieces of functionality in the TBO would freeze, objects would get out of sync until the method server was restored and the doSave() function invoked for all failed pieces. This would happen about 3 - 4 times a year. At that point I found that for critical steps in the business process, I had to cache / pool a superuser session local to the TBO being downloaded.

That way whether it was Webtop, DFS, CMIS, custom DFC app or whatever, it was all self contained and if method server failed, the business process was maintained.

Back on AliasSet topic

I'm actually using this caching mechanism to create the alias sets on the fly in the TBO. I took your advice Panfilov and checked to see if alias exists, If it didn't, i can actually pattern it off of a default alias set and have an alternate process change the values of the alias set as needed. I think your solution for mixing AliasSets and ACLs is an awesome solution and makes maintainence so much easier. I can use ACLs to set securty based on Document Centric data groups and AliasSet to set security based on User Centric data groups.

I can normalize my data and have security change dynamically. I'm putting together a presentation for the rest of the developers in my group to show that AliasSets can be used for more than environment variables for workflow.

SOAPBOX:

Not to use this to get on a soap box, but EMC's migration away from a "Content Server Centric" (BOF, TBO, SBO) solution to "Application Centric" (D2, XCP) really sucks. I can deal with the Classloader issues that BOF is infamous for. Encapsulating business logic with the BOF ensures that no matter what channel I use (GUI, CMIS, DFS, Custom, etc...), i don't have to recode. This feeble excuse that it creates web services that apps can invoke doesn't ENFORCE other channels to use it.

PanfilovAB


However, I found that the method server would, from time to time, fail for one reason or another.  Since key pieces of functionality in the TBO would freeze, objects would get out of sync until the method server was restored and the doSave() function invoked for all failed pieces.  This would happen about 3 - 4 times a year.  At that point I found that for critical steps in the business process, I had to cache / pool a superuser session local to the TBO being downloaded.

We went through the same path, i.e. method -> admin session singleton. Now we're using dynamic groups for privilege escalation (real life example: , have no idea why it does work for me but does not work for amgravem)


Not to use this to get on a soap box, but EMC's migration away from a "Content Server Centric" (BOF, TBO, SBO) solution to "Application Centric" (D2, XCP)  really sucks.  I can deal with the Classloader issues that BOF is infamous for.  Encapsulating business logic with the BOF ensures that no matter what channel I use (GUI, CMIS, DFS, Custom, etc...), i don't have to recode.  This feeble excuse that it creates web services that apps can invoke doesn't ENFORCE other channels to use it.

Actually, the problem is modern ecm developers are totally unqualified, yes, it's more simple (but not correct) to put business logic in application rather than business object, and thus create a quick and dirty solution, but that leads to another problem: you should implement and maintain the same logic in all applications. EMC is turning has turn the best ECM platform into expensive alfresco competitor

ndegroff

I've spent many years integrating applications to ERP and ECM systems. One of the first major development lessons I learned was creating a bolt on to an ERP system. It was a web GUI and we had to enforce logic about warehouse bins and cycle counting that could not be housed in the ERP system itself. The problem was it depended on EVERYONE going in through the GUI to perform their transactions. Not 10 days into the implementation, the system had inaccurate counts and the logic was blown. Apparently some old hands liked using their outdated interface and made transactions the old fashioned way. It was a mad scramble to resync the systems and MANDATE that no one could use the product except through the GUI.

I'm currently working on a project right now helping a SalesForce team integrate with Documentum and they are making the same mistakes. They want to use features only available to Documentum, but enforce logic at the SF level. Now they have to bastardize the system, keep duplicate data in both systems and recode logic at the lower tier.

Keep logic in the tier it belongs - I think of it like a Hub and spoke model with the "Content Server" in the center and your interfaces like web services and GUI on the periphery. Keep your GUI logic in your GUI, your web service logic in your web services, but your document centric logic in the center.

Where Documentum is going - I understand they are retooling the Content Server into some sort of Information Center where everything is an aspect. I see by getting their clients to bind the logic up in the GUI decoupled from the Content Server is looking forward to transitioning clients to a new system. However, I think that goal is short-sighted.

Documentum's history with periphery apps - Take a look at how many times Documentum web services were changed till they finally landed on DFS. If you were an early adopter, it sucked to be you. Same thing with xCP Taskspace and the new xCP2.0. Still not backwards compatible. We support multiple ECM tools where Documentum is just one of many. My clients adore CMIS. .NET apps / Java Apps / CustomRESTful apps are MUCH easier to integrate than DFS. Logic bound up in a GUI doesn't translate well to this.

I know this commentary takes it way far off the initial thread's purpose, but it feels good to vent to a larger audience than my team. I'm sure they're tired of listening to me rant.