Hand-picked user assistance content from the LiveCycle community
Posts tagged administration
Canonical name ‘vs’ User ID
0331 days
Issue:
Recently I worked on a customer issue where in they were seeing an error when the user logged into their AIR client on MAC and was unable to access the application.
The error seen was :
LC_AuthenticateUser Error: com.adobe.idp.um.api.UMException| [com.adobe.idp.um.api.impl.AuthenticationManagerImpl] errorCode:16386 errorCodeHEX:0×4002 message:user_identifier:Z027223 domain:DefaultDomcom.adobe.idp.common.errors.exception.IDPException| [com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean] errorCode:13316 errorCodeHEX:0×3404 message:user_identifier: Z027223 domain:DefaultDom;
---
Read the complete post at Adobe LiveCycle Blog.
Managing User Access
0331 days
You must have the Application Administrator role assigned to your LiveCycle ES2 user account in order to develop applications. In this role, you can assign limited access to the application development environment for users who have other roles assigned. You can permit other users to have the following type of access:
- Read: The user can view the application.
- Delegate: Although the user is not the Application Administrator, that user can extend read/write permissions to another user.
- Write: The user can modify the application and save the changes.
Essentially one can classify user permissions under the following two categories:
- Role Based Permissions
- Resource Level Permissions
Role Based Permissions typically would cover the roles that the user has been assigned via the Role Assignment interface and this supersedes the “Resource Level Permission ” which are assigned via the Manage Access interface as described in the following link.
In order to achieve the above scenario one would need to ensure that the user has not been assigned any such permissions which would otherwise allow the user to perform the Read/Delegate/Write operations on an application.
---
Read the complete post at https://blogs.adobe.com/livecycle/2012/07/managing-user-access.html.
Configuring LiveCycle JDBC Data Sources in WebLogic for DB Failover
0505 days
For IBM WebSphere, see here.
LiveCycle ES2′s Configuration Manager (LCM) provides you two options for configuring JDBC data sources in WebLogic:
1) Package it inside the EAR files (more secure)
2) Create it in the WebLogic Admin Console
Choice #2 provides a lot more flexibility when it comes to configuring the data sources for database failover. Runtime configuration changes such as increasing the pool size can be done without having to un-deploy and re-deploy EAR files.
To ensure that the connections in the connection pool are valid, the following additional configuration changes are necessary. This is based on an actual customer deployment against an active-passive SQL Server database cluster. You can make changes as necessary to fit your IT environment.
1) In the ‘Connection Pool‘ tab for the JDBC data source, in the ‘Advanced‘ section, ensure that the checkbox for ‘Test Connections on Reserve‘ is checked
2) Set ‘Test Frequency‘ to 10 seconds
3) Set ‘Test Table Name‘ to “DUAL” or “EDCJOBENTITY”
4) Set ‘Seconds to Trust an Idle Pool Connection‘ to 5 seconds
5) Set ‘Init SQL‘ to “SQL SELECT * FROM DUAL” or “SQL SELECT COUNT(*) FROM EDCJOBENTITY”
6) Set ‘Connection Creation Retry Frequency‘ to 12 seconds
7) Set ‘Login Delay‘ to 0 seconds
8) Set ‘Inactive Connection Timeout‘ to 0 seconds
9) Set ‘Connection Reserve Timeout‘ to 10 seconds
——-
Original article at http://blogs.adobe.com/livecycle/2011/04/configuring-livecycle-jdbc-data-sources-in-weblogic-for-db-failover.html.
Disabling Session Re-Writing in BlazeDS and LCDS
0534 days
Session re-writing is the practice of adding the session identifier to the HTTP request URL instead of passing the session identifier as a session cookie. Session re-writing is usually used when cookies have been disabled on the client. It is an easy way to let clients that do not allow or support cookies maintain session state with the server but it poses some security risks. The session identifier is passed in the URL which means that it is not encrypted even if the request is made over SSL/HTTPS. Because of the security risks associated with session re-writing, the Open Web Application Security Project (OWASP) recommends that session re-writing only be used for low-value sites. In this article, I will show you how to disable session re-writing in BlazeDS and LCDS to help secure your application.
In BlazeDS and LCDS, the session identifier is typically either the JSessionId (for servlet based endpoints in BlazeDS or LCDS) or AMFSessionId (for NIO HTTP based endpoints in LCDS).
Note that the RTMP protocol doesn’t use HTTP, so the issue of session re-writing doesn’t apply to RTMP endpoints.
When the BlazeDS or LCDS server receives a request with no session identifier (either a session cookie or session id URL parameter) a couple things happen. A new session is created. A Set-Cookie header with the session id is added to the response. Also, an AppendToGatewayURL header with the session id is added to the AMF or AMFX response message.
Using the Belgian eid card for accessing a LiveCycle Rights Management protected document
0666 days
Disease:
Typically LiveCycle Rights Management (a.k.a. Policy) protected documents use a userid/password mechanism for authenticating towards the policy server, and consequently open the protected document. A more secure way of authentication can be obtained by using client certificates. A real strong way of authentication can be accomplished when the authentication certificate resides on a smartcard, protected by a PIN code. The authentication certificate on the Belgian eid card is such an example. How can that be used to authenticate towards a Policy protected document?
Prescription:
To achieve this follow these steps:
1) First of all the authentication certificate must be known/registered/uploaded to the LiveCycle server. Open the adminui –> Settings –> Trust Store Management –> Certificates.
When importing the .cer file, specify that you want to trust the certificate for “Certificate Authentication”, and provide an alias.
2) Next this certificate must be mapped to an existing user in LiveCycle.
Open the adminui –> Settings –> User Management –> Configuration –> Certificate mapping.
The mapping between a certificate and a user is done for a defined alias, and is accomplished by mapping a certificate attribute (Mail, CN, DN,… ) to a user property (Full Name, Given Name, Mail, login ID, …).
In the case of the Belgian eid card the CN on the authentication certificate contains also the word “Authentication”. In my case my CN = Peter Schellemans (Authentication). So in order to get a working certificate mapping towards an existing user, make sure you have a user with a similar Full Name. In my case I have a user (adminui –> Settings –> User Management –> Users and Groups) with First Name = Peter, Last Name = Schellemans (Authentication).
3) Next add this user as part of your Policy. When opening the policy protected document you will now get the choice between userid/password authentication and client certificate authentication.
Tip to stay healthy:
If you want a higher level of security when authenticating towards a policy protected document, Adobe LiveCycle allows you to map certificates towards users, used in a policy definition.
—-
Original article at http://www.drflex.eu/2009/01/using-the-belgian-eid-card-for-accessing-a-livecycle-rights-management-protected-document/?utm_source=rss&utm_medium=rss&utm_campaign=using-the-belgian-eid-card-for-accessing-a-livecycle-rights-management-protected-document.
Workspace Polling in ADEP
0666 days
ADEP Workspace now allows Administrators to modify the Workspace client polling interval without having to recompile the Workspace source code. A new Global Configuration setting is added to the Workspace Global Configuration settings xml file that allows Administrators to modify the client polling values. The new setting is called ‘client_pollingInterval’ and the default value is 3 seconds.
To modify the client polling value:
- Log in to the ADEP Administator Console and navigate to Home-> Services-> Workspace-> Global Administration and click the ‘Export’ button in the ‘Export global settings’ area.
- Save the ‘AdminGlobalSetting.xml’ file to your local file system.
- Open the file and locate the ‘client_pollingInterval’ tag and change the value to your new value.
- Save the file.
- In the Workspace Global Administration page click the Browse button in the ‘Import global settings’ area and locate the AdminGlobalSettings.xml file and then click the Import button. (No server restart is required.)
The next time your end users log in to Workspace they will be using this new polling interval.
——-
Original article at http://blogs.adobe.com/ADEP/2011/08/workspace-polling-in-adep.html.
Configuring Limits For LiveCycle Workbench Recordings
0791 days
I learned something new today and figured it was worth sharing for other people that didn’t realize these settings existed. On a call I was asked why recordings of a process would stop after a certain number of steps and how that can be configured. Honestly, I didn’t even realize we limited this, though now that I do it does make sense as a good idea to avoid having recordings take up a massive amount of disk space. So I took the question offline and dug into it.
It turns out there are two configuration parameters to set limits for recordings done in Workbench. The setting can be found and configured in Adminui under Services->Applications and Services->Service Management. Select the AuditWorkflowService service, and then click the Configuration tab. The two settings are:
- maxNumberOfRecordingInstances – This is the maximum total number of recorded processes that will be allowed on the server at any time. By default the value is 50. When you go to record the 51st process the 1st process recording will be deleted from the server to make room for the new one.
- maxNumberOfRecordingEntries – This is the maximum total number of steps in a process that will be saved in a recording. By default the value is 50. If a process being recorded consists of 75 steps, then the first until the 50th step will be saved into the recording. Steps 51 to 75 will not be saved.
The first parameter is nice to know about, but I think in most cases having a history of 50 process recordings will be sufficient. It’s the second parameter that is most likely to cause problems for people when trying to debug large processes. To that end if you see the following warning in your server’s log file you’ll now know that your running into this limit and need to change the value accordingly:
WARNING: stop recording entries due to space limitation.
——-
Original article at http://blogs.adobe.com/livecycle/2011/04/recording-limits.html.
