Configuring WS-Security for Epic

[#1]

When configuring the Epic application, it's a best practice to secure the Epic Interconnect Personnel Management/Security Web Service endpoint using WS-Security, at the moment (as of 7.2 GA) IdentityIQ doesn't support WS-Security for the Core endpoint.  Below are the steps to enable WS-Security in the Epic application in IdentityIQ:

1. Copy the sailpoint_epic_connector_axis2.xml and epic_security_policy.xml files to the \WEB-INF\classes\ directory
2. Add the following entries the Epic application xml through debug (sample data that should be replaced with instance specific information):
   • <entry key="engageWSSecurity" value="true"/>
   • <entry key="authUserID" value="local:epicsailpoint"/>
   • <entry key="authUserPassword" value="2:yqq3acVTnn2HpKdfTJr0gA=="/>

The authUserID and authUserPassword entries differ from the username/password entered into the application when configuring through the UI.  This is the account that should be configured for the Interconnect Web Service when enabling WS-Security and doesn't need to exist within the Epic application (EMP Record).

In the above sample data, the Epic team created a local account (doesn't exist in Active Directory just in the Epic Interconnect configuration) which is why the authUserID is prefixed with local:

For Active Directory accounts, the authUserID will need to be prefixed with windows: (i.e. windows:epicsailpoint)

[Eric_Mendes_CISSP]

This worked as expected, but this should be updated to reflect the process for windows domain based interconnect accounts.

In order to use a windows domain based account, the authUserID needs to be prefaced with "windows:" instead of "local:", so for example "windows:epicsailpoint".

Cheers!

[jom]

Great point.  I've updated the article to reflect that.

I added one additional note as well.  As of IdentityIQ 7.2 GA, WS-Security is only supported for the Personnel Management/Security endpoint.  It doesn't support it for the Core endpoint.  I believe it's being worked on and will be supported soon, but currently it's not.

[Eric_Mendes_CISSP]

Great additional point! I'm in the middle of an Epic deployment and was informed WS-Security for the Core endpoint would be arriving with the IIQ 7.3 GA.

Cheers!

[kbeckwith]

Please add this to the connector guide, we were dead in the water until I found this article.

[kbeckwith]

Hello Eric,

Do you have the configuration you used to make the windows authentication work in the EPIC Interconnect interface?

I understand that specifying windows: works but every time I try it I get the smooth connectivity error.

"[ ConnectionFailedException ] [ Possible suggestions ] Ensure the Epic system host is reachable and there is a smooth connectivity between Identity Server and Epic host. [ Error details ] Failed to connect to Epic System. At least one security token in the message could not be validated."

I am running 7.3 p1

[Eric_Mendes_CISSP]

Hey Kyle,

Based on that error message, I would confirm with the Epic team that they have implemented WS-Security for both the core binding and personnel management API calls. Or try disabling one or the other in the IIQ configuration.

I had a similar issue during our deployment which stemmed from the Epic instance only being configured to enforce WS-Security for the core binding. Our connector version (7.2p2 w/ an eFix) was sending the additional security token for all API calls, but since the Epic instance was not expecting the additional security token for personnel management API calls, Epic would throw an exception and the API call would fail. We discovered this issue via a WebEx with SailPoint engineering, but instead of waiting for another eFix, the Epic admins enabled WS-Security for both end-points and that resolved our issues. Looks like the 7.3p1 Epic connector allows you to enable/disable per end-point, which is great and most likely resulted from the issues we discovered in the field.

Cheers!

[checlever]

jom​,

Does the prefix local: need to be added only to the authUserID or also commonWSSecurityUserName, coreWSSecurityUserName, and siteName? We are getting the following error and can't figure out how to solve it:

[ ConnectionFailedException ]  [ Possible suggestions ] Ensure the Epic system host is reachable and there is a smooth connectivity between Identity Server and Epic host.  [ Error details ] Failed to connect to Epic System. The message could not be processed. This is most likely because the action 'urn:Epic-com:Security.2014.Services.PersonnelManagement.ViewUser' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.

We are on 7.3p1

[rockmus]

The prefixes should only be added in the WS-Security Setting section.  The siteName cannot contain any prefixes and must be a valid EMP record in Epic.

To the others on this thread and beyond, I was wondering if anyone knows the exact level of access that needs to be granted to the "siteName" (admin) account within Epic to be able to aggregate and provision.  The customer is concerned: a) that someone can log into Hyperspace with this account; b) that this account will have too much access. 

Ilya

[sunnyajmera]

I am on 7.3p2 and getting the same error. Can you share the fix.

I have tried adding windows or local prefix to the username but nothing helped. This is the error I am getting on test connection:

ConnectionFailedException: [Possible Suggestions] Ensure the epic system host is reachable and there is smooth connectivity between SailPoint and Epic Host. Error Details: failed to connect to EPIC System. The message could not be processed. This is most likely because the action 'urn:Epic-com:Security.2014.Services.PersonnelManagement.ViewUser' is incorrect or because the message contains an invalid or expired security context token or because there is mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the receive timeout on the service endpoint's binding.

[checlever]

This is what fixed the issue for us. In debug add entry <entry key="soapVersion" value="1.1"/> Note that in the setup guide it suggests to set value to 1.2 "if your company is using SOAP 1.2". Well, the module doesn't work for SOAP 1.2. We worked with SailPoint ENG team and they said nobody else is using SOAP 1.2. So add the entry and make sure that in the interconnect site they enable SOAP 1.1

Also, no where in the setup guide says how to setup the users. The only way we could make it work was by having the interconnect team create a local user account on the server hosting Epic interconnect. That is used for the WS-Security section. Then we had the Epic team create a regular EMP record (it can't be a background record) with the right security to create/modify EMP records. We setup the security the same as our Epic provisioning team. The EMP needs to be Active and it can be set to Epic Native. You don't even need to set the System Login. Just set the .1 to whatever you want. We used SPADMINPRD for .1. Below is our configuration. Feel free to PM me if you have any other questions.