SUP DCN User Role

The SUP DCN User is a logical role that Unwired Platform uses to authorize any DCN event: updating data in the cache, executing an operation, or triggering a workflow package.

Before any DCN event is submitted, the person or group mapped to this role must be authenticated and authorized by the security configuration used. By default, SUP DCN User is automatically available to all new security configurations you create. However, the underlying default varies depending on the environment in use.

In a development environment – A physical role called DCNRole is automatically added to the OpenDS LDAP directory. The SUP DCN User logical role is mapped to the DCNRole physical role, which is group automatically added to this directory. Both the supAdmin and supDcnDeveloper LDAP users are added as members of DCNRole, so either user may perform DCN.
In a production environment – In a single domain environment, the "default" Domain's security configuration has "no security" set by default. That means, any user/password credentials are authenticated, and all roles are granted to everyone. So any user could perform DCN initially.
However, eventually this default configuration for the default domain will change. In this case—as in the case for any additional security configurations that is added—the SUP DCN User logical role must be mapped to some physical role in the backend security systems, and the user who performs DCN must be in that physical role.

Note: If security configuration provider does not support roles, you must perform a special mapping manually. You can create a single user role (a role explicitly mapped to a single user authenticated against the particular security configuration). This is achieved by prefixing the username with user:. For example, a mapped physical role named user:joep would authorize the user named 'joep' to issue DCN to any package associated with the particular security configuration that contains this mapping, or to issue a workflow DCN to any user authenticated against the particular security configuration.

To map the SUP DCN User to a user in the underlying security repository, the user name must be first defined in Sybase Control Center as a physical role that is mapable. Then, SUP DCN User role can be mapped to a physical user or to a physical role from Sybase Control Center. For example, if you want to map SUP DCN User to a user use the format user:<User> . Alternatively, you can also map it to a role with <PhysicalRole>.
If you are supporting multiple domains, then the user name also needs to include the named security configuration for the package the DCN is targeted for, by appending @<DomainSecurityConfigName> as a suffix to that name. Suppose you have two packages (PKG_A, PKG_B) deployed to 2 domains (Domain_A, Domain_B) respectively. Further, assume that PKG_A in Domain_A has been assigned to the "admin" security configuration, whereas PKG_B in Domain_B has been assigned to the "alternateSecurityConfig" security configuration.
- A user doing DCN to PKG_A should identify themselves as User@admin.
- A user doing DCN to PKG_B should identify themselves as User@alternateSecurityConfig.
If you are using ActiveDirectory, and are using email addresses for user names, then definitions appear as <username@myaddress>@<DomainSecurityConfigName>.

Furthermore, the implementation varies depending on the DCN service used:

For workflows, because the resource the user is pushing data towards is a group of named users (users authenticated previously successfully against a certain security configuration), therefore the user must have the authorization to push to that particular security configuration. The user must have be mapped to SUP DCN User in the security configuration for the workflow target.
A user having SUP DCN User logical role in security configuration 'mySecConfig1' must not have the right to push workflow DCN or regular DCN to a user or package associated with 'mySecConfig2'.