| Oracle Agile Engineering Data Management Security Guide Release e6.2.0.0 E52560-02 |
|
 Previous |
 Next |
| Oracle Agile Engineering Data Management Security Guide Release e6.2.0.0 E52560-02 |
|
Previous |
Next |
LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying directory services running over TCP/IP.
With Agile e6.2.0.0, LDAP based authentication is supported. While an Agile e6 user is logging in to the Agile e6 system through any supported client, the password of that user will be verified with the one stored in the LDAP repository. There is no additional validation or storage of the password within EDM.
The communication between the EDM Server and the LDAP repository has to be set up. Each Agile e6 user, as configured in the Agile e6 database, has to be available in the LDAP repository in order to be authenticated at login.
|
Note: Although LDAP support enables only ONE password for many different systems, it should not be confused with automatic Single-Sign-On (SSO) support. This would allow a user to log on automatically, without being asked to provide user login and password! |
LDAP Server (Oracle Internet Directory / MS Active Directory / other LDAP server).
Oracle LDAP Client (part of the Oracle client installation).
LDAP configuration site-specific sites are created in DDM Site Vaults and can be used in all modules. To create a DDM Site Vaults refer to the Online Help > General Replication.
|
Note: For the module "General Replication", the license "Distributed Objects" is required and has to be active. |
An Agile e6 user name and an LDAP user name must have been created.
|
Note: The Agile e6 user name and the LDAP user name don't need to be identical. But it is required that the LDAP user name is configured in the Agile e6 system. |
An LDAP directory is often used to manage users and organization units in a central environment. Products like the Oracle Internet Directory are able to manage users, groups, and organization units in a standard LDAP environment and are compatible with the most other LDAP servers which are based on the LDAP standards.
|
Note: For more information on password policy for Oracle Internet Directory, refer to OID documentation on http://www.oracle.com/technetwork/documentation/oid-089101.html. |
With Agile e6.2.0.0, the LDAP authentication mechanism supports the authentication of an Agile e6 user password against an LDAP repository.
The LDAP for Agile e6.2.0.0 uses the Base-DN for a direct access path to authenticate the user. LDAP integration does not support relative search paths.
|
Note: Security features like changing the password, locking/unlocking accounts etc. and any policies like password length etc. are managed in the external LDAP system and not in the Agile e6 system. |
By mapping an Agile e6 user to a Remote Credential, you can change the used login mechanism of an Agile e6 user.
Typically, an Agile e6 user has a different user name in the LDAP repository, therefore a remote user name field is supported to map the user names. To support multi-domains in LDAP, the administrator can link each user to the site specific LDAP configuration.
For more information about the Credential Mapping see the Online Help for DataView > Enhanced User Management.
The LDAP system takes care of the password policies (expiration and format).
|
Note: The enhanced security module and the possibility to change the password within Agile e6 are deactivated for LDAP users. |
The LDAP configuration used by the Agile e6 system is stored in the database (T_CFG_DAT) as configuration parameters.
| Configuration Parameter | Default Value | Description |
|---|---|---|
| EDB-LDAP-HOST | <LDAP-host> | LDAP host name |
| EDB-LDAP-HOST-<number> | <LDAP-host> | Backup LDAP host name (optional). See chapter "Support Backup LDAP Server for Fail Over" below for further information. |
| EDB-LDAP-PORT | - | LDAP service port (=default port depends on encryption mode) |
| EDB-LDAP-BASEDN | cn=users, dc=example, dc=com | Base DN of the user group |
| EDB-LDAP-RDN | cn | Relative DN of the user (optional) |
| EDB-LDAP-ENCRYPTION | Yes | LDAP encryption mode (yes=SSL, no=unsecure) |
| EDB-LDAP-WALLET-LOCATION | - | Path to the Oracle Wallet which contains the LDAP server certificate (UNIX only) |
The configuration entries are site specific to support multi-domains. For each site, different LDAP settings can be configured.
|
Note: Only default and site-specific LDAP configuration parameters are supported. Language-specific parameters are not supported. |
|
Note: LDAP supports SSL and it is recommended to enable SSL for the LDAP connection. |
To secure the LDAP connection, the LDAP server certificate must be installed on the EDM Server. The mechanism to install the LDAP server certificate is different on Windows and UNIX.
|
Note: The following information applies to self signed as well as to official certificates. |
Windows
The LDAP certificate has to be installed in the Windows Certificate Store.
UNIX
The LDAP certificate has to be imported into the Oracle wallet. The location of the Oracle wallet is configured in the database in the LDAP configuration parameter.
SSL Encryption on UNIX
Create an Oracle Wallet by using the Oracle Wallet Manager.
This is part of the database client installation.
Import the LDAP server certificate as trusted certificate into the Oracle Wallet.
Activate the auto login feature of the Oracle Wallet.
Save the Oracle Wallet to a secure location, e.g. $ep_root (example /app/plm6).
Login in to Agile e6 with a manager user.
Configure the LDAP server configuration parameters to use the Windows active directory.
Example:
EDB-LDAP-HOST: ldap.example.com
EDB-LDAP-BASEDN: CN=Users,DC=example,DC=com
EDB-LDAP-ENCRYPTION: yes
EDB-LDAP-WALLET-LOCATION: file:/app/plm6
Configure an Agile e6 user to use the LDAP to login.
Map Agile e6 user to an LDAP user.
Login to Agile e6 by using the Agile e6 user which is configured to use LDAP.
SSL Encryption on Windows
Logon on Windows EDM Server with the runtime account of the Agile e6 system (e.g. axalanrt user)
Normally you get two certificates from your LDAP system administrator which have to be imported into your EDM Server.
The Certificate Authority (CA) Certificate must be imported into "Trusted Root Certificate Authorities" group.
The LDAP Server Certificate has to be imported into the "Other People" group.
Microsoft provides a program to test an LDAP connection. The program is called ldp.exe and can be downloaded from Microsoft Support.
Open ldp.exe.
Enter your server name.
Enter your port number.
If required, activate SSL.
Click OK.
The output should look like this for a successful test:
ld = ldap_sslinit("ldap.example.com", 636, 1);
Error <0x0> = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
Error <0x0> = ldap_connect(hLdap, NULL);
Error <0x0> = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 128 bits
Established connection to ldap.example.com.
Retrieving base DSA information...
Result <0>: (null)
Matched DNs:
To setup a backup LDAP server:
To start, use the same configuration as described above.
To configure a backup LDAP server, add a new configuration parameter with EDB-LDAP-HOST-1.
|
Note: You can configure an unlimited amount of backup LDAP server (EDB-LDAP-HOST-1, EDB-LDAP-HOST-2, ...). |
The Java Client SSO feature bases on Kerberos. The Java Client uses the Windows logon Ticket Granting Ticket (TGT) to request a service ticket for the Agile e6 system.
The Agile e6 user has to be mapped to the Windows domain user so that the Agile e6 system can automatically log into the Windows domain user with its mapped default Agile e6 user account.
For more information about user credential mapping refer to the Online Help DataView > Enhanced User Management.
The following sections explain how you can configure your Agile e6 system to support the Kerberos based SSO feature.
The graphic shows an overview of all tasks to prepare the customer infrastructure to use the Kerberos integration.Tasks on the left side show System Administrator tasks, while tasks on the right side are executed by an Agile e6 Administrator.
All examples are based on a Microsoft Windows Domain environment with a domain login and a Domain Controller with an Active Directory.
Some of the tasks are manual steps for installation and configuration of the Kerberos integration. The other tasks are administration tasks of the Windows domain.
In general, there are two tasks which must be completed before you can configure an SSO environment for the Java Client.
Collect the information of your company Kerberos infrastructure and create the krb5.ini configuration file for Java.
Request the Service Principals and get the corresponding keyTab files from your Kerberos administrator.
The Java Runtime environment of the Agile e6 J2EE components need some basic information about the company Kerberos infrastructure.
For a standard configuration you need the following information:
Name of your domain
Host name of the Kerberos server
This information must be provided by your Kerberos administrator. In the most common cases you will have a Windows domain with a domain controller as Kerberos server.
|
Note: If the configuration file already exists, please modify it, otherwise create it new. |
The Java Runtime uses the JAAS Kerberos module to verify the Kerberos service tickets provided during the login.
The krb5.ini configuration file describes the settings used by the JAAS Kerberos module. This configuration file is normally located at C:\Windows on a Windows system.
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = false
dns_lookup_realm = false
ticket_lifetime = 600
default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc
[realms]
EXAMPLE.COM = {
kdc = kdc.example.com
default_domain = EXAMPLE.COM
}
[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true
Here a short description of the most important settings:
default_realm
Default realm which should be used. This is the name of the Windows domain used for login.
kdc
The realm definition with the name of the Kerberos server (kdc) and the domain name. The domain name must be in uppercase! The kdc is normally the domain controller.
default_domain
In this example the Windows domain is EXAMPLE.COM and the domain controller has the hostname "kdc.example.com."
The configuration file for a Windows domain can use the DNS lookup to locate the KDC for the Windows domain. So it is not necessary to configure the hostname of the KDC, the system finds the KDC for the domain automatically.
For more information about creating a new configuration file, please refer to the following on-line documentations:
Kerberos Requirements
http://docs.oracle.com/javase/7/docs/technotes/guides/security/jgss/tutorials/KerberosReq.html
How to Manually Configure a Kerberos Client
http://docs.oracle.com/cd/E19253-01/816-4557/setup-341/index.html
To store the configuration file krb5.ini for later usage during the Agile e6 J2EE components configuration, we recommend storing it in a secret location.
When installing the configuration file krb5.ini, it can be stored in two different places:
C:\Windows
The default location.
Application specific
To minimize possible side effects with other Java application, it is possible to install the Java Kerberos configuration file application specific.
How this can be achieved is described in section Agile e6 J2EE Components Configuration.
The Kerberos authentication for services works with so called Service Principal Names (SPN). These are special service accounts on the Kerberos server.
The Kerberos administrator needs the hostnames where the service is running and the service name to create such a Service Principal Name.
In case of Agile e6, the SPN pattern is AgileEDM/hostname@DOMAIN.
As the used environment defines for which server(s) you need to request a Service Principal Name, the Agile e6 environment needs to be defined first.
The following picture shows some common installation bases which demonstrate how to identify the servers which need the Service Principal Name.
Example Configurations - Load Balancer
In this example, the different clients connect to a load balancer server which routes the clients to different EDM Servers. The Agile e6 J2EE components are deployed on an extra server which is used by the different EDM servers.
In such a configuration, the load balancer is the entry point for the different clients which are running the Agile e6 Java Client. Therefore, the Service Principal has to be created for the load balancer server and not for the EDM servers which are behind the load balancer.
The keyTab for the load balancer has to be installed on the Agile e6 J2EE server for the verification of the Kerberos service tickets.
Example: Different EDM Servers
In this configuration, some client machines are connecting to the EDM Server 1 and the other client machines are using the EDM Server 2, the Agile e6 J2EE components are deployed on these servers, too.
In this use case we need two Service Principals, one for each EDM server and the keyTab files have to be installed on corresponding Agile e6 J2EE components deployment.
Example: Different protocols to access the Agile e6 Server
This environment has one EDM Server which can be accessed in different ways. Some client machines are using the socket based ECI protocol to access the EDM Server directly.
Other client machines are connecting via HTTP/S (PLM-API) to the Agile e6 J2EE server to login into Agile e6.
In this scenario we need two Service Principals, one for the EDM server, and one for the Agile e6 J2EE server. Both keyTab files have to be installed on the Agile e6 J2EE server.
As you have seen in the examples, not all servers need a Service Principal Name. It depends on how the Java Clients are connected to the Agile e6 system.
In general, the server which is used for the login (hostname to access the Agile e6 system) needs the Service Principal Name and the keyTab needs to be installed on the corresponding Agile e6 J2EE components deployment.
In the examples, the Windows domain is EXAMPLE.COM, therefore the Service Principal names (SPN) are:
Load Balancer Example
AgileEDM/lb.example.com@EXAMPLE.COM
Different Agile e6 Servers Example
AgileEDM/edm1.example.com@EXAMPLE.COM
AgileEDM/edm2.example.com@EXAMPLE.COM
Different Protocols to access the Agile e6 Server Example
AgileEDM/edm.example.com@EXAMPLE.COM
AgileEDM/j2ee.example.com@EXAMPLE.COM
The Active Directory administrator has to create a Service Principal for the Login Server.
To achieve this; the administrator needs to create a mapping user which will be used to map to the Service Principal.
If the customer infrastructure needs more than one Service Principal Name (one for each login server), it is recommended to add the server name to the mapping user name.
For example, you want to create a mapping user to map to a Service Principal Name for the EDM Server, which is running on edm.example.com.
Create a mapping user like e.g. AgileEDM_edm.example.com.
You can see for which service on which host the mapping user is used.
The Service Principal Name itself has to be named with this pattern:
AgileEDM/hostname@DOMAIN in this example it would be AgileEDM/edm.example.com@EXAMPLE.COM.
By mapping the user account, created for the Service Principal Name, a keyTab file is written, which is needed by the Agile e6 J2EE components to verify Kerberos tickets for that Service Principal Name.
With the ktpass util program from Mircosoft, you can map the mapping user to the Service Principal Name and export the key table which can be used by the the Agile e6 J2EE components to verify the Kerberos service tickets for that Service Principal Name.
ktpass /princ AgileEDM/edm.example.com@EXAMPLE.COM /mapuser AgileEDM_edm.example.com@EXAMPLE.COM /pass mapuserpassword /out krb5.keytab /crypto all /ptype KRB5_NT_PRINCIPAL /mapop set /kvno 0 Targeting domain controller: kdc.example.com Successfully mapped AgileEDM/edm.example.com to AgileEDM_edm.example.com. Password succesfully set! Key created. Key created. Key created. Key created. Key created. Output keytab to krb5.keytab: Keytab version: 0x502 keysize 71 AgileEDM/edm.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x1 (DES-CBC-CRC) keylength 8 (0x7f085b1f62498a08) keysize 71 AgileEDM/edm.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x3 (DES-CBC-MD5) keylength 8 (0x7f085b1f62498a08) keysize 79 AgileEDM/edm.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x17 (RC4-HMAC) keylength 16 (0x0d2c584ff099e7eda13b6f5312f14782) keysize 95 AgileEDM/edm.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x12 (AES256-SHA1) keylength 32 (0x9d208948196e2d869d9d9648fc7f478aad2244940ab17344939d4f7b33abdea4) keysize 79 AgileEDM/edm.example.com@EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 0 etype 0x11 (AES128-SHA1) keylength 16 (0x61150efafb64635fd247b677a18e4840)
In this example, the keytab file contains all supported encryption algorithms of the KDC.
For Windows Domain Controllers, the RC4-HMAC is the standard.
See MSDN help for more information.
To store the keyTab files for later usage during the Agile e6 J2EE components configuration, we recommend storing it securely. It may the best practice to name the keyTab file so that it is clear for which Service Principal Name it is used for.
For example, the keyTab for AgileEDM/edm.example.com@EXAMPLE.COM can be named like edm.example.com.keytab.
You can also use different sub directories to organize your keyTab files for the several login servers.
The EDM Server delegates the Kerberos login request to the security module, located within the Agile e6 J2EE components, which are deployed on the WebLogic server.
The following graphic shows the different steps to configure the Agile e6 J2EE components for the Kerberos integration.
Create secured directory
Install Java Kerberos configuration file
Install keytab file(s)
Configure your Service Principal(s)
Populate Kerberos configuration to WebLogic Server
Install Oracle Wallet
Re-deploy
Restart domain
The Agile e6 J2EE server needs several configuration files and keytab files exported from the Kerberos server (Active Directory).
These files contain security relevant information and must be protected.
As best practice, you can store the files within the WebLogic installation at the following location:
%DOMAIN_HOME%\..\..\security
Example:
Your domain directory of your Agile e6 J2EE server installation may be located at:
D:\Oracle\Middleware_WLS1212\user_projects\domains\eSeries_domain
Then you can create the secure directory at:
D:\Oracle\Middleware_WLS1212\user_projects\security
|
Note: Make sure that the WebLogic runtime user has access only to this directory!Do not create the secure directory within the eSeries_domain, because it may be deleted by the admin client. |
During the preparation of the Kerberos prerequisites, the Java Kerberos Configuration file (krb5.ini) was created.
Copy that file into the new secure directory.
You got the keyTab file(s) from your Kerberos administrator.
Copy them into the new secure directory.
You can copy them all into the secure directory with different file names or create a sub directory for each keyTab file.
In the following are some examples of secure directory configurations with more than one keyTab file.
All in one Directory
krb5.ini
edm1.example.com.keytab
edm2.example.com.keytab
j2ee.example.com.keytab
jaas.conf
Sub Directories
conf
krb5.ini
jaas.conf
keytab
edm1.example.com
krb5.keytab
edm2.example.com
krb5.keytab
j2ee.example.com
krb5.keytab
In the example above, the jaas.conf configuration file is listed. This configuration file allows binding the Service Principal Names to their keyTab file.
In this section we will create that configuration file.
Template
This template can be used to create the jaas.conf configuration file:
<hostname> {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="<full path to the keytab file>"
storeKey=true doNotPrompt=false
isInitiator=false
principal="<Service Principal>";
};
Template for IBM AIX
On IBM AIX the jaas.conf file looks different:
<hostname> {
com.ibm.security.auth.module.Krb5LoginModule required
credsType=acceptor
useKeytab="<full path to the keytab file>"
principal="<Service Principal>";
};
For each Service Principal Name the jaas.conf file has to contain such a section.
The common settings are pre-configured in this example, for detailed information for the possible settings please refer to the JAAS Login Configuration File documentation on docs.oracle.com.
You need to provide the following information:
The Agile e6 J2EE component uses the hostname as key to find the entry in the configuration.
The full path to the keyTab file.
|
Note: The full path always has to use the UNIX style syntax "/"! |
The Service Principal Name without the domain.
Example: "Sub directories" example:
edm1.example.com {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="D:/Oracle/Middleware_WLS1212/user_projects/security/edm1.example.com/krb5.keytab"
storeKey=true
doNotPrompt=false
isInitiator=false
principal="AgileEDM/edm1.example.com";
};
edm2.example.com {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="D:/Oracle/Middleware_WLS1212/user_ projects/security/edm2.example.com/krb5.keytab"
storeKey=true
doNotPrompt=false
isInitiator=false
principal="AgileEDM/edm2.example.com";
};
j2ee.example.com {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="D:/Oracle/Middleware_WLS1212/user_ projects/security/j2ee.example.com/krb5.keytab"
storeKey=true
doNotPrompt=false
isInitiator=false
principal="AgileEDM/j2ee.example.com";
};
To create the file jaas.conf:
Open an editor.
For each Principal Service Name add such an entry.
Save it into your secure directory with the file name jaas.conf.
The Kerberos configuration files must be populated to the application domain server of the Agile e6 J2EE server. The Java JAAS module supports 2 system properties which allow configuring the location of the configuration files.
-Djava.security.krb5.conf=<full path to the krb5.ini file> -Djava.security.auth.login.config=<full path to the jaas.conf file>
Example:
The WebLogic console of the Agile e6 J2EE Server allows setting the security system properties.
Navigate via Environments -> Servers to the eSeries server of your application domain.
On the tab "Server Start" set the system properties in the Arguments text box.
Example: Script based Example
With the WSLT tool from WebLogic, you can set the system properties like this:
cd('/Servers/eSeries-01/ServerStart/eSeries-01'
cmo.setArguments('-Djava.security.krb5.conf=D:\Oracle\Middleware_WLS1212\user_projects\security\conf\krb5.ini -Djava.security.auth.login.config=D:\Oracle\Middleware_WLS1212\user_projects\security\conf\jaas.conf'
activate()
The configuration of Kerberos is very complex. In case Kerberos does not work, here some hints to track down what could be wrong.
Possible Errors - The creation of the Kerberos Ticket failed
If the user changes the login type to "Kerberos", the user name should be changed to the Kerberos user name automatically. If this does not happen, the Java Client cannot access the TGT of the Windows session.
If the Java Client shows the error that the SSO ticket cannot be created, it may be a configuration issue within the krb5.ini file.
Activate the Java Client logging and trace com.agile.security package to get more information.
If you get an invalid user/password message, the Kerberos ticket could not be verified or the trusted relationship did not work.
To get more information, activate the EDM Server tracing.
Open or create a custom environment start-up script (<application>_cust.cmd) in the %ep_root%\init directory of your EDM Server installation.
Add to the custom environment start-up script the following setting:
set EP_DEBUG=Main,Epq
This activates the server trace including the SQL trace.
To activate the C++ trace:
Open the environment XML file <application>.xml at the same location as the start-up script.
Edit the TraceConfig attribute of the General section.
Set the name of the trace configuration file.
The default trace configuration file is located in the %ep_root%\axalant\ini directory and is named as trace.cfg.
Here an example for the use of the default trace configuration file.
TraceConfig="F:D:\plm\axalant\ini\trace.cfg"
Open the trace.cfg and activate the following entry:
com::agile::dtv debug
The EDM Server writes a log file into the tmp directory of your EDM Server installation.
User Mapping
You can use the SQL statements within the log file to check if a valid user mapping was found.
Search for SELECT on T_USERMAP.
At least one record has to be found.
Kerberos ticket verification
If your Kerberos ticket cannot be verified, you will find the error message in the log file.
Search for PlmLogin to find Kerberos ticket verification errors.
Trust of relationship
For errors in the trust of relationship, you will also find the error message in the EDM Server log file. In most cases the reason for errors here are access permission issues with the Oracle wallet files, or inconsistencies between the Oracle wallet provided to the EDM Server, and the Oracle wallet provided to the J2EE components.
For a detailed description for the configuration of the Web Services, see the Web Services Guide for Agile e6.2.0.0.
The remote credential of type LDAP, used for the Web Service call, must have a valid default mapping to an Agile e6 user.
The mapped Agile e6 user has to have the Web Service flag activated. The Web Service flag is activated in the Agile e6 user management.
Configuration parameter EDB-WSI-URL must be set to the Web Service URL for the Agile e6 Core Web Service (https://<server>:<port>/CoreServices).
Other configuration parameters for Web Service Configuration must be set dependent of the called Web Services.
For more information about the user credential mapping refer to the Online Help DataView > Enhanced User Management.
The Security Assertion Markup Language (SAML) enables cross-platform authentication between web applications, or Web Services running in a WebLogic server domain and web browsers, or other HTTP clients. WebLogic server supports single sign-on (SSO) based on SAML. When users are authenticated at one site that participates in a single sign-on (SSO) configuration, they are automatically authenticated at other sites in the SSO configuration and do not need to log in separately.
To use SSO based on SAML for Web Service calls, you have to configure a trusted relationship between the WebLogic domains and the application domain server of the Agile e6 J2EE server.
See the Oracle WebLogic Server documentation, "Understanding Security for Oracle WebLogic Server" how to configure SAML.
Agile e6 Web Service target resources that can be configured to accept authentications through SAML assertions:
target:*:/CoreServices/BusinessObjectService target:*:/CoreServices/ConfigurationService target:*:/CoreServices/DocumentManagementService target:*:/CoreServices/MetadataService target:*:/CoreServices/ECService
To be able to call the Web Services with SAML authentication, you have to adapt the file web.xml and file weblogic.xml:
Copy the files from directory %ep_root%\staging\product\application\<application_name>\WebServices\agile-ws-e6-jws-core.war\WEB-INF\
to directory:
%ep_root%\staging\custom\application\<application_name>\WebServices\agile-ws-e6-jws-core.war\WEB-INF\.
Remove in file web.xml sections:
<security-constraint>…. </ security-constraint>
<login-config>…</login-config>
<security-role> … </security-role>
Remove in file weblogic.xml section
<security-role-assignment> … </ security-role-assignment >
|
Note: After applying the SAML policy to a Web Service, you are no longer able to call this Web Service without a SAML authentication. |
