X

Deep dive into various configurations with Oracle Weblogic Server

Recent Posts

Weblogic Security

Steps to configure SAML SSO with Azure (as IDP) and Weblogic Server (as SP)

Below are the steps to configure SAML 2.0 SSO with Azure as Identity Provider (IDP) and Weblogic as Service Provider (SP). Let's have a look at the Azure Identity Provider configuration first : Azure IDP Configuration  Step 1 :  Login to Azure portal -> Azure Active Directory -> Enterprise Applications : Step 2 : Create a new application : Step 3 : Select Non-gallery application -> add your own application  Step 4 : Select Single Sign-On -> SAML  Step 5 : Step 6: Download the IDP metadata. NOTE: User attributes and claims that need to be part of the SAML Token sent to WLS can be edited from this screen. Step 7 : Azure IDP metadata cannot be used with Weblogic directly as it contains few tags that are not supported by Weblogic. Edit the IDP metadata downloaded in Azure and remove the <RoleDescriptor> tag. This tag should be present twice in the metadata. Save the metadata. This will be used to create a partner in Weblogic SP configuration. Step 8 : You can add users who need access to this application as required. Weblogic SP Configuration : Step 1: Create SAML Identity Provider and SAML Authentication provider in Weblogic. SAML Identity Provider is required to understand/accept the SAML token sent from Azure to WLS. SAML Authentication Provider is an optional provider which can be created if you want to make use of the "Virtual User" feature in WebLogic. Step 2 : Restart the servers. After restart select Adminserver -> Federation Services -> SAML2.0 General : NOTE : In this example I am configuring SSO for the WLS console application which is deployed to the Admin Server by default, hence I need to update the SAML2.0 General tab under AdminServer. If you have your custom application deployed on say MS1 then you need to update the SAML2.0 General tab of the managed server, say MS1. Publish site URL should have the URL in the following format : https://<publicly_accessible_host_or_IP>:<publicly_accessible_port>/saml2 If you have a Load Balancer behind Weblogic then Publish Site URL should contain the Load Balancer host and the port. Irrespective of what application is deployed on Weblogic the Publish Site URL should always have the context as "/saml2", because saml2.war is an internal application deployed in Weblogic and it cannot be changed. Entity ID should be a unique name in WLS.  Step 3 : Enable SAML2.0 service provider. Default URL is optional. Step 4: Now go back to "SAML 2.0 General" tab and publish the SP metadata. NOTE: The file name should have an extension .xml Step 5 : Now go to Security Realms -> Providers -> SAML Identity Asserter -> Management  and create a new partner using the modified Azure IDP metadata. Step 6 : Enable the partner created and update the Redirect URI. NOTE : Redirect URI should be the context of the protected page of your application that needs to participate in SSO. In our case it is "/console/*" If you want to bypass SSO and access the WLS console directly use the following URL : https://<host>:<port>/console/login/LoginForm.jsp (continued) Azure IDP configuration : Step 9 : Now use the SP metadata and create a partner in Azure.   Step 10 : Since we are testing SSO using the console application, you need to change the cookie name for console application in Weblogic : Now when you access the console page you should get redirected to Azure IDP login page : <Additional Info> If you would like to test SSO with a sample application (instead of WLS console), then : Deploy the following sample application on Weblogic Server (Weblogic_SP_sample_App.zip) DOWNLOAD  "Weblogic_SP_sample_App.zip" NOTE: You can just unzip the above zip file and deploy the application in an exploded format in WLS.(There is no need to create a war file). To enable this application to participate in SSO add the redirect URI as shown below : Login to console -> security realms -> myrealm -> Providers -> <saml_IA> -> management -> <partner_name> -> Redirect URIs : /Weblogic_SP_sample_App/restricted/protected_page.jsp  

Below are the steps to configure SAML 2.0 SSO with Azure as Identity Provider (IDP) and Weblogic as Service Provider (SP). Let's have a look at the Azure Identity Provider configuration first : Azure...

A Simple Guide to docker installation on Oracle Linux 7.5

Below are the steps to install docker using Oracle YUM repository: Step 1. Set your proxy : Command : export http_proxy=xxx.xxx.xxx.xxx:80 Command : export https_proxy=xxx.xxx.xxx.xxx:80 Step 2. Take a backup of existing public-yum-ol7.repo : Command : cd /etc/yum.repos.d/ Command : mv /etc/yum.repos.d/public-yum-ol7.repo /etc/yum.repos.d/public-yum-ol7.repo_org1 Step 3. Download the latest public-yum-ol7.repo from Oracle YUM repository: Command : wget http://yum.oracle.com/public-yum-ol7.repo Step 4. Make the following changes in your public-yum-ol7.repo file: Command : vi public-yum-ol7.repo [ol7_latest] name=Oracle Linux $releasever Latest ($basearch) baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/latest/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1 [ol7_UEKR4] name=Latest Unbreakable Enterprise Kernel Release 4 for Oracle Linux $releasever ($basearch) baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/UEKR4/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1 [ol7_UEKR3] name=Latest Unbreakable Enterprise Kernel Release 3 for Oracle Linux $releasever ($basearch) baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/UEKR3/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=0 [ol7_optional_latest] name=Oracle Linux $releasever Optional Latest ($basearch) baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/optional/latest/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1 [ol7_addons] name=Oracle Linux $releasever Add ons ($basearch) baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/addons/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 enabled=1 Step 5. Reboot your machine: Command : systemctl reboot Step 6. Install docker using Oracle yum repository: Command :  yum install docker-engine Step 7. Enable docker service: Command : systemctl enable docker Step 8. Start docker service: Command : systemctl start docker Step 9. Check the status: Command : systemctl status docker.service Step 10. Check if docker client and server was installed successfully: Command : docker version Step 11. Try to login to Docker hub: Command : docker login Run the following commands If you are unable to connect to the Docker hub: Command : mkdir -p /etc/systemd/system/docker.service.d Command : vi /etc/systemd/system/docker.service.d/http-proxy.conf and append the following: [Service] Environment="HTTP_PROXY=xxx.xxx.xxx.xxx:80" "HTTPS_PROXY=xxx.xxx.xxx.xxx:80" "NO_PROXY=localhost,127.0.0.1" Command : systemctl daemon-reload Command : systemctl restart docker check if proxy was set properly: Command : systemctl show --property=Environment docker Try to login again using : Command : docker login

Below are the steps to install docker using Oracle YUM repository: Step 1. Set your proxy : Command : export http_proxy=xxx.xxx.xxx.xxx:80 Command : export https_proxy=xxx.xxx.xxx.xxx:80 Step 2. Take a...

Fusion Middleware

Steps to configure SAML 2.0 with Oracle SAAS as IDP and Oracle Java Cloud Service as SP

Service Provider Configuration at JCS : Click on the following hyperlink to download the sample application : JCS_SSO_Test_application.zip (Unzip this file and deploy) Step 1 : Since JCS is acting as a Service Provider (which accepts a token), we need to create a SAML Identity Asserter provider from console : Login to console -> Security Realms -> myrealm -> Providers -> Authentication -> new : Step 2 : Now select the server where SSO application will be deployed and navigate to "Federation Services" as shown below : Login to console -> +Environment -> Servers -> <server_where_SSO_application_will_be_deployed> -> Federation Services -> SAML 2.0 General : Two most important fields here are : - Published Site URL : <protocol>://<public_host>:<public_port>/saml2  // This URL should always contain an external host:port. // Protocol can be http or https. // URL should always contain "/saml2" at the end. (This is an internal application deployed in WLS and cannot be changed). - Entity ID : <Any_name> ( This is a Unique identifier) Other fields are optional and can be left blank. Step 3 : Restart your servers. Step 4 : Navigate to SAML 2.0 Service Provider tab : Login to console -> +Environment -> Servers -> <server_where_SSO_application_will_be_deployed> -> Federation Services -> SAML 2.0 Service Provider : Make sure you that "Enable" checkbox is checked. Step 5 : Navigate to SAML 2.0 General and export the SP metadata : Login to console -> +Environment -> Servers -> <server_where_SSO_application_will_be_deployed> -> Federation Services -> SAML 2.0 General -> Click on "Publish Meta Data" Save the metadata with an extension .xml Step 6 : Now open an SR with SAAS team and provide this metadata and ask them to create an SP partner in SAAS. Step 7 : SAAS team will create a partner for SP and provide their IDP metadata. Step 8 :  IDP metadata provided by SAAS contains additional information in it, which has to be manually removed to get it working with JCS  Open the IDP metadata in a text editor like Notepad++ and search for : - md:SPSSODescriptor Now remove this entire tag. Then search for : - md:RoleDescriptor Remove this entire tag. Now copy the modified IDP metadata to JCS instance. Step 9 : Now let's create a partner for IDP in JCS using the modified IDP metadata  Navigate to the Identity Asserter you created earlier to create the partner : Login to console -> Security Realms -> myrealm -> Providers -> Authentication ->SAML_IA -> Management -> New -> "New Web Single Sign-On Identity Provider Partner" Select the modified IDP metadata and click OK. Step 10 : Click on the newly created IDP partner -> Enable (check) Step 11 : To avoid manually creating all the users in SAAS on to JCS, we can make use of a feature called Virtual User. Which is enabled by default. However, this gets activated only when a SAML Authenticator provider is configured. Lets create that now. Login to console -> Security Realms -> myrealm -> Providers -> Authentication -> New ->  Type : SAMLAuthenticator  Step 12 : Since we have multiple Authentication Providers now, we need to change the control flag Login to console -> Security Realms -> myrealm -> Providers -> Authentication -> Default Authenticator -> Control Flag -> "Optional" Step 13 : Restart your VM now. Step 14 : Now lets test if SSO is working fine using a sample application : Download "JCS_SSO_Test_application.zip" and deploy it to the server where Federation Services was configured. Step 15 : Now lets set the "Redirect URI" for this application to enable SP initiated SSO Login to console -> Security Realms -> myrealm -> Providers -> Authentication ->SAML_IA -> Management -> WebSSO-IdP-Partner-0 Redirect URIs : /JCS_SSO_Test_application/restricted/protected_page.jsp Step 16 : Create a test user in SAAS called "saas_testuser" or you can use any user who is part of "Administrator" group. Step 17 : Now when you access the protected page of JCS_SSO_Test_application you will be redirected to IDP login page asking for a challenge. Access URL: http://<host>:<port>/JCS_SSO_Test_application/restricted/protected_page.jsp After you are successfully authenticated in IDP you should be able to see the protected page of JCS_SSO_Test_application. Success : Failure : Step 18 : Cloud-specific APIs are not provided for any logout functionalities. However, the application can safely redirect to /oamsso/logout.html, which is the mechanism responsible for invalidating the SSO cookie. This URL takes an optional parameter end_url which can be assigned a URL to which you will be redirected after logout, e.g. in a JSP: <%   response.sendRedirect("/oamsso/logout.html?end_url=/public-and-secured-application");   // this will logout and redirect to the fully public part of the example application %> Refer : https://docs.oracle.com/en/cloud/paas/javase-cloud/csjsu/securing-applications-oracle-java-cloud-service-saas-extension.html  

Service Provider Configuration at JCS : Click on the following hyperlink to download the sample application : JCS_SSO_Test_application.zip (Unzip this file and deploy) Step 1 : Since JCS is acting as a...

Configuring WLS Web Server Proxy Plug-In for Apache HTTP Server

I will be covering the following topics in the blog post : Apache Plug-in configuration with Weblogic over HTTP Apache Plug-in configuration with Weblogic over HTTPS - OneWaySSL Apache Plug-in configuration with Weblogic over HTTPS - TwoWaySSL     Before we Begin : Download the Supported Configuration matrix from the following link and verify that you are using a supported version of Apache, WLS plugin and Weblogic Server in your environment. Link: http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html Download the xls file and then click on the "WebServer" tab to get a list of supported Web Servers and their compatible versions. Pre-Requisites : 1) Install Apache and Weblogic Server 2) Create a Weblogic domain with two managed servers in a cluster.  3) Download Oracle WebLogic Server Proxy Plugins from the following link : Link: http://www.oracle.com/technetwork/middleware/webtier/downloads/index-jsp-156711.html       Steps to configure Apache 2.x with Weblogic Server using WLS Plugin : Click here to go Back to Index Request Flow : Client ----HTTP---> Apache ---HTTP---> Weblogic Weblogic ----HTTP----> Apache -----HTTP-----> Client  For this sample configuration I am using Apache 2.4, Weblogic Server 12.2.1.3 and WLS plugin version 12.2.1.3 Step 1 : Unzip the downloaded WLS Plugin zip file to any location, say "ApachePlugin12.2.1.3.0". Step 2 : Take a backup of httpd.conf file located in  "<Apache_home>/conf"  and make the following changes to it :  Add an entry for LoadModule as follows : LoadModule weblogic_module  /refresh/home/ApachePlugin12.2.1.3.0/lib/mod_wl.so NOTE: Make sure that all the other .so files are present in the same location where "mod_wl.so" is located. Add the following IfModule : <IfModule mod_weblogic.c> WebLogicHost xx.xx.xxx.xxx WeblogicPort 7001 </IfModule> <Location /> SetHandler weblogic-handler </Location> NOTE: Here we are forwarding the request to a single WLS server running on port 7001. If you want to forward the request to a cluster you can use the following : <IfModule mod_weblogic.c> WebLogicCluster xx.xx.xxx.xxx:7003,xx.xx.xxx.xxx:7005 </IfModule> <Location /> SetHandler weblogic-handler </Location> Here Weblogic server with port 7003 and 7005 are part of a cluster in Weblogic Server domain. Step 3: Ensure that the ${PLUGIN_HOME}/lib is included in the LD_LIBRARY_PATH: $ export LD_LIBRARY_PATH=/refersh/home/ApachePlugin12.2.1.3.0/lib Alternatively, you can copy the content of "/refersh/home/ApachePlugin12.2.1.3.0/lib" to APACHE_HOME/lib OR You can also edit APACHE_HOME/bin/apachectl to update the LD_LIBRARY_PATH       Steps to configure Apache 2.x with Weblogic Server using WLS Plugin  over one-way SSL Click here to go Back to Index Request Flow : Client ----HTTP---> Apache ---HTTPS---> Weblogic Weblogic ----HTTPS----> Apache -----HTTP-----> Client  Here SSL is configured on Weblogic Server. Weblogic Server acts as an SSL Server and Apache acts as an SSL client. Pre-Requisites : 1) Enable SSL on Weblogic domain. By default DemoIdentity and DemoTrust will be configured. You need to trust the root certificate of WLS in WLSPlugin. 2) Make sure that you are able to access the application deployed on Weblogic over SSL. Step 1: Create and configure wallet in Apache using the following commands : Command: orapki wallet create -wallet my-wallet -auto_login_only Import the root certificate of Weblogic in wallet using the following command : Command: orapki wallet add -wallet my-wallet -trusted_cert -cert /referesh/home/Oracle/Middleware/Oracle_Home/wlserver/server/lib/CertGenCA.der -auto_login_only Step 2: Modify the IfModule in httpd.conf file as follows : <IfModule mod_weblogic.c> WebLogicHost xx.xx.xxx.xxx WeblogicPort 7002 SecureProxy ON WLSSLWallet /refresh/home/ApachePlugin12.2.1.3.0/bin/my-wallet” </IfModule> <Location /> SetHandler weblogic-handler </Location> Step 3: Ensure that the ${PLUGIN_HOME}/lib is included in the LD_LIBRARY_PATH: $ export LD_LIBRARY_PATH=/refersh/home/ApachePlugin12.2.1.3.0/lib Alternatively, you can copy the content of "/refersh/home/ApachePlugin12.2.1.3.0/lib" to APACHE_HOME/lib OR You can also edit APACHE_HOME/bin/apachectl to update the LD_LIBRARY_PATH       Steps to configure Apache 2.x with Weblogic Server using WLS Plugin  over two-way SSL  Click here to go Back to Index Request Flow : Client ----HTTP---> Apache ---HTTPS---> Weblogic Weblogic ----HTTPS----> Apache -----HTTP-----> Client  Here SSL is configured on Weblogic Server. Weblogic Server acts as an SSL Server and Apache acts as an SSL client. Pre-Requisites : 1) Create a self-signed certificate. You can refer to the following link for more details on the same : Link: https://blogs.oracle.com/blogbypuneeth/steps-to-create-a-self-signed-certificate-and-configure-custom-identity-and-custom-trust-with-weblogic-server-using-keytool 2) Now lets enable two-way SSL : Login to console -> +Environment -> Servers -> <Server_name> -> SSL -> +Advanced -> Select "Client-Cert Requested and Enforced" from the drop-down. Step 1: Create and configure wallet in Apache using the following commands : Command: orapki wallet create -wallet my-wallet -auto_login_only  Import the root certificate of Weblogic in wallet using the following command : Command: orapki wallet add -wallet my-wallet -trusted_cert -cert /referesh/home/Oracle/Middleware/Oracle_Home/wlserver/server/lib/CertGenCA.der -auto_login_only  Create a self-signed certificate with wallet using the following commands : Command: orapki wallet add -wallet "/refresh/home/ApachePlugin12.2.1.3.0/bin/my-wallet" -auto_login_only -dn "CN=celvpvm09188.us.oracle.com,OU=wls,O=wls,L=Bangalore,ST=Karnataka,C=IN" -keysize 2048 -self_signed -validity 2048 Export the root certificate of the self-signed certificate we created in the previous step. List the contents of wallet :   Step 2: Modify the IfModule in httpd.conf file as follows : <IfModule mod_weblogic.c> WebLogicHost xx.xx.xxx.xxx WeblogicPort 7002 SecureProxy ON WLSSLWallet /refresh/home/ApachePlugin12.2.1.3.0/bin/my-wallet” </IfModule> <Location /> SetHandler weblogic-handler </Location> Step 3: Ensure that the ${PLUGIN_HOME}/lib is included in the LD_LIBRARY_PATH: $ export LD_LIBRARY_PATH=/refersh/home/ApachePlugin12.2.1.3.0/lib Alternatively, you can copy the content of "/refersh/home/ApachePlugin12.2.1.3.0/lib" to APACHE_HOME/lib OR You can also edit APACHE_HOME/bin/apachectl to update the LD_LIBRARY_PATH Step 4: Import the root certificate of Apache in Weblogic trust store :   NOTE : We are configuring SSL between Apache and WLS and not between the client and Apache. So the URL you access will be http://<apache_hostname>:<apache_port>/console     Click here to go Back to Index

I will be covering the following topics in the blog post : Apache Plug-in configuration with Weblogic over HTTP Apache Plug-in configuration with Weblogic over HTTPS - OneWaySSL Apache Plug-in...

Steps to create partitions in WLS 12.2.1

Below are the steps to create partitions in Weblogic Server 12.2.1 : Step 1 : - Create a weblogic domain (say Partition_From_Windows_Domain) FMW control is the recommended console for Partition management, so it is good to enable it at the time of  domain creation.   To enable FMW control select "Oracle Enterprise Manager-Restricted JRF - 12.2.1 [em]" template in the configuration wizard, as shown below : To access FMW control access : http://<host>:<port>/em NOTE : We will continue using Weblogic Admin console to create partitions in this example. Partition names : coke-partition and pepsi-partition Partition specific realms : coke_realm and pepsi_realm Partition specific Admin Users : coke_admin and pepsi_admin Virtual Targets for these partitions : coke-vt and pepsi-vt Partition Specific Resource Groups : coke-rg1 and pepsi-rg1 Step 2 : Before creating a partition, you need to create a security realm (then create an Admin user inside this realm, say coke_admin and pepsi_admin) and virtual target for this partition : To create a new security realm : Login to console -> Security Realms -> new (say 'coke_realm' and 'pepsi_realm') -> "create default providers within this new realm" (check) Now create a Virtual target : Login to console -> + Environment -> Virtual Targets -> new (say coke-vt) and target it to Weblogic Server (say Admin Server) -> specify a URI Prefix Step 3 : Lets create a partition now : Login to console -> Domain Partitions -> new (say coke-partition)-> then target it to a Virtual target (say coke-vt) -> select the security realm for this partition from the drop down menu (say coke_realm)  Step 4 : Create a Resource Group inside domain partition  Step 5 :  Check the Identity Domains of the partitions : Step 6 : You can now deploy applications to Global scope / to a resource group of a partition To access the application deployed to your partition use the following URL : http://<host>:<port>/coke/Weblogic_SP_sample_App/login.jsp  ==> Try to login with the coke Admin and also test the login using weblogic user. Perform similar tests with application deployed on pepsi-partition and global scoped deployment.

Below are the steps to create partitions in Weblogic Server 12.2.1 : Step 1 : - Create a weblogic domain (say Partition_From_Windows_Domain) FMW control is the recommended console for Partition...

Weblogic Security

Steps to configure SAML 2.0 with Okta as IDP and Weblogic as SP

Below are the steps to configure SAML 2.0 with Okta as Identity Provider and Weblogic as a Service Provider. Okta IDP configuration : Step 1 : Log-in to your Okta subdomain homepage to access the Application Dashboard. Now click on Applications -> Add Application -> Create New App -> select SAML 2.0 -> create Step 2 : Follow the on-screen instructions. Create a SAML integration as shown below : Enter the following : Single sign on URL : <https://<weblogic_sp_hostname>:<port>/saml2/sp/acs/post Use this for Recipient URL and Destination URL (check) Audience URI : This would be the entity ID that you will be specifying in your WLS SP ( Make a NOTE of what you have entered here, we need to use the same in --> WLS console->Federation Services->SAML2 General-> EntityID) NOTE : - Unlike other SAML configurations we are not importing the SP metadata into Okta IDP, instead we fill-in the above values manually. - Hence it is important to make a NOTE of the Audience URI (i.e SP entity ID) and use the same in Weblogic SP configuration. Step 3 : We have successfully created a SAML Integration, now lets download the IDP metadata (say Okta_IDP_for_WLS-metadata.xml) from the Sign On sub-tab : Step 4 : Go to People sub-tab and assign users to your application : Step 5 : Click on the General sub-tab and validate your IDP configuration. Step 6 : Login to Okta with the user who was assigned this application : Your Okta IDP configuration is now complete, lets configure Weblogic as a SAML Service Provider. Weblogic SAML SP configuration : Step 1 : Login to Weblogic console -> Security Realms -> myrealm -> Providers -> Authentication -> new -> SAML2IdentityAsserter Step 2 : Click on the newly created SAML2IdentityAsserter (say SAML2IA) -> Management -> new -> "new Web Single Sign-On Identity Provider Partner" (say WebSSO-IdP-Partner-0) Select the metadata.xml file that you downloaded from Okta (say Okta_IDP_for_WLS-metadata.xml) Step 3 : Click on the newly created IDP partner and enter the following : Enable (check) Redirect URIs : /Weblogic_SP_sample_App/restricted/protected_page.jsp Step 4 : Click on the Server (where the IDP application is deployed) -> Configuration -> Federation Services -> SAML 2.0 General -> and enter the following : Publish Site URL : https://celbealnx1.us.oracle.com:8002/saml2 Entity ID : WLS_SP_for_Okta Step 5 : Click on Server (where the IDP application is deployed) -> Configuration -> Federation Services -> SAML 2.0 Service Provider -> and enter the following : Enabled (check) Preferred Binding : POST Default URL : https://celbealnx1.us.oracle.com:8002/Weblogic_SP_sample_App/restricted/protected_page.jsp You have successfully configured Okta IDP with Weblogic SP. Time to test it now :) Deploy the sample application on Weblogic (Weblogic_SP_sample_App.zip) DOWNLOAD  "Weblogic_SP_sample_App.zip" Now open the Okta page -> click on the application and check if the protected page of application deployed on WLS is accessible. NOTE : - Okta sends the login name (i.e email address) by default in the SAML token to Weblogic. - If you want to retrieve the Firstname of the user to authenticate into the protected page of Weblogic SP application, then make the following changes in Okta : Login to Okta dashboard as Admin -> Directory -> Profile Editor Click on "Apps" -> "Mapping" next to your application Click on "Okta to Okta_IDP_for_WLS" -> Select "firstName" from the dropdown -> "Apply mapping on user create and update" -> "Save mapping" Now test your application...!!!

Below are the steps to configure SAML 2.0 with Okta as Identity Provider and Weblogic as a Service Provider. Okta IDP configuration : Step 1 : Log-in to your Okta subdomain homepage to access the...

How to store database credentials in Oracle Wallet (for WLS datasource definitions)

Oracle Wallet can be used to securely store the database credentials. Multiple credentials for multiple database can be stored in a single wallet file. Below are the steps to create a datasource which uses Oracle wallet to store database credentials : Step 1 : Create a wallet in a secured location : Command :   $ORACLE_HOME/oracle_common/bin/mkstore -wrl <wallet_location> -create   Step 2: Add database login credentials to the wallet  Command :  $ORACLE_HOME/oracle_common/bin/mkstore -wrl <wallet_location> -createCredential <db_connect_string> <username> <password> Step 3 : Create a new datasource as shown below : This is how you used to create a datasource in WLS using a DB username / password : Now you can specify a wallet in the datasource configuration (and avoid using DB username / password) : ">NOTE the change in DB connection URL format :  It is changed from "jdbc:oracle:thin:@//xxxx:1521/sl11g" to "jdbc:oracle:thin:/@xxxx:1521/sl11g"  <Additional Info> Command to list the credentials stored in a wallet : $ORACLE_HOME/oracle_common/bin/mkstore -wrl <wallet_location> -listCredential Command to modify credential stored in wallet : $ORACLE_HOME/oracle_common/bin/mkstore -wrl <wallet_location> -modifyCredential <dbase_alias> <username> <password>  Command to delete credentials stored in a wallet : $ORACLE_HOME/oracle_common/bin/mkstore -wrl <wallet_location> -deleteCredential <db_alias> 

Oracle Wallet can be used to securely store the database credentials. Multiple credentials for multiple database can be stored in a single wallet file. Below are the steps to create a datasource which...

Steps to modify analytics application ( OBIEE 11.1.1.7) to work with SSO

Below are the steps to modify the analytics application to login using SSO :  - Create a new folder (say "modified") and copy the analytics.ear file to it. NOTE : analytics.ear file is located @ Eg : "/refresh/home/app/obiee/Oracle_BI1/bifoundation/jee/"  - Now run the following command to explode the analytics.ear file : Command : jar -xvf analytics.ear  Delete the analytics.ear file from "modified" folder.  You should have the following files in "modified" folder now :  1. analytics-ws.war  2. analytics.war  3. META-INF   -  Edit the MANIFEST.MF file located in META-INF folder to add the following : Weblogic-Application-Version: 11.1.1.7.0.130303.2025  NOTE : This step is optional - Create a folder called "tmp"  and move analytics.war file to it, then explode it using the following command : Command : jar -xvf analytics.war -  Edit the web.xml file located in "tmp/WEB-INF" folder and add the following : NOTE : Replace  <login-config>     <auth-method>CLIENT-CERT</auth-method>  </login-config>  with the following :  <security-constraint> <web-resource-collection> <web-resource-name>BI Analytics</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>SSORole</role-name> </auth-constraint>              </security-constraint> <login-config>    <auth-method>CLIENT-CERT</auth-method> </login-config>    <security-role> <role-name>SSORole</role-name>   </security-role> - Now edit the weblogic.xml file as follows :  <?xml version = '1.0' encoding = 'US-ASCII'?><weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">   <context-root>analytics</context-root> <security-role-assignment> <role-name>SSORole</role-name> <principal-name>puneeth</principal-name> <principal-name>BIUsers</principal-name> <principal-name>BIAdmins</principal-name>                <principal-name>BISystemUser</principal-name> </security-role-assignment>   <!-- Bug 14659820.         The oracle.bibopmn library would pull in a version of the sautils.jar which do not access to a mad.jar         with appropriate codegrants. Due to updgrade restrictions we need to keep using the war's jars.       -->   <container-descriptor>       <prefer-web-inf-classes>true</prefer-web-inf-classes>   </container-descriptor></weblogic-web-app> NOTE : You have to specify the users / groups that need access to the analytics application in <principal-name> tag.  - Create a war file using the following command : Command : jar -cvf analytics.war * - Copy this newly create analytics.war file to "modified" folder and delete the "tmp" folder that we created earlier.  - "modified" folder should contain the following now : 1. analytics.war (modified) 2. META-INF folder (which contains the modified MANIFEST.MF ) 3. analytics-ws.war (unchanged original file).  - Create an ear using the following command : Command : jar cvfM analytics.ear analytics.war analytics-ws.war META-INF/ - Take a back of the original analytics.ear file - Login to console and stop "bi_server1" - Delete the "analytics.ear" application from console -> deployments tab - Replace the original "analytics.ear" file with the modified ear file. - Now login to console -> start "bi_server1" and deploy the modified "analytics.ear" file. - Make sure that the application is in active state and test SSO. 

Below are the steps to modify the analytics application to login using SSO :  - Create a new folder (say "modified") and copy the analytics.ear file to it. NOTE : analytics.ear file is located @ Eg...

Weblogic Security

Steps to configure SAML SSO with ADFS (as IDP) and Weblogic Server (as SP)

Below are the steps to configure SAML 2.0 SSO using ADFS as Identity Provider and WLS as Service Provider. In this example I am using ADFS 2.0 on Windows Server 2008R2. Let's have a look at the ADFS IDP configuration first : Step 1 : Download and install ADFS 2.0 - Create a Federation Server  Step 2 : - Create a self signed certificate and configure SSL on IIS  Step 3 : - Start ADFS 2.0 Management / Configuration Wizard  - Create a new Federation Service  - Select the self-signed certificate you created using IIS from the drop down menu.  - Lets create a Stand-alone federation server for this example. If you want to use the high-availability / load balancing feature in ADFS then create a Federation server Farm. We have now completed the configuration of AD FS 2.0. Step 4 :  To download the AD FS metadata (i.e IDP metadata in our case) access the following link : https://<ADFS_hostname>/federationmetadata/2007-06/federationmetadata.xml  NOTE : - Metadata downloaded from ADFS contains information about both SP and IDP. It also contains few tags which are not supported by WLS. - Remove the following tags from federationmetadata.xml  : (a) <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ..........  </X509Data></KeyInfo></ds:Signature> (b) <RoleDescriptor xsi:type="fed:ApplicationServiceType" ...........  </EndpointReference></fed:PassiveRequestorEndpoint></RoleDescriptor> (c) <RoleDescriptor xsi:type="fed:SecurityTokenServiceType" ...........  </EndpointReference></fed:PassiveRequestorEndpoint></RoleDescriptor> (d) <SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">  ........... </SPSSODescriptor>  The final edited federationmetadata.xml file is as follows : Step 5 :   - Export the self-signed certificate you created in IIS to .pfx file (say adfscert.pfx). Convert this pfx file to .jks using the following command : Command : keytool -importkeystore -srckeystore adfscert.pfx -srcstoretype PKCS12 -srcstorepass password -destkeystore identity.jks -deststoretype JKS -deststorepass password  - Copy the identity.jks and modified federationmetadata.xml to Weblogic box. Step 6: Weblogic SP configuration :  - Configure "Custom Identity and Custom Trust" on Admin Server using the identity.jks file that you copied from ADFS box. NOTE : To reduce the complexity of this configuration I am avoiding creation of two separate certificates/keystores on ADFS box and WLS box.  - Create an Identity Asserter using Weblogic Admin console. Login to Weblogic console --> Click on ” myrealm ” –> ” Providers ” –> ” Authentication ” –> new ” SAML2IdentityAsserter “ say " saml_IA " : - Create an AD provider and retrieve the users from Active Directory. (Alternatively, you can create a new SAMLAuthenticator provider and enable the " virtual user " feature in WLS SP).  - Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Service Provider ” and make the following changes : Enabled : check Preferred Binding : POST Default URL : http://<DestinationSiteDNSName>:<PORT>/console Now click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes : Replicated Cache Enabled : Uncheck  Contact Person Given Name Contact Person Surname Contact Person Type Contact Person Company Contact Person Telephone Number Contact Person Email Address Organization Name Organization URL Published Site URL : https://<DestinationSiteDNSName>:<PORT>/saml2 Entity ID : ( Destination Domain name) Single Sign-on Signing Key Alias Single Sign-on Signing Key Pass Phrase Confirm Single Sign-on Signing Key Pass Phrase Recipient Check Enabled : Uncheck - Save the changes and export SP metadata into an XML file  ( say sp.xml ) –> Click on “ Publish Meta Data ” button. - Create an IDP partner on Weblogic using the federationmetadata.xml file you copied from ADFS box. Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> Authentication -> saml_IA –> ” Management ” –> ” New ” –> “ New Web Single Sign-On Identity Provider Partner ” say ” WebSSO-IdP-Partner-1 ” and then select ” federationmetadata.xml ” : Click on ” WebSSO-IdP-Partner-1 ” and enter the following : Name : WebSSO-IdP-Partner-1 Enabled : Check Description : WebSSO-IdP-Partner-1 Redirect URIs : /console/* Step 7 : ADFS IDP configuration : - Add a Replying Party Trust using ADFS 2.0 Management wizard - Import the replying party data into ADFS IDP using the SP metadata file that you copied from WLS box (i.e sp.xml) Step 8 :  - We have completed all the SP and IDP related configuration now. It time to test SSO :) - To access an SP initiated SSO access the following link : https://<WLS_hostname>:7002/console - Once you access the console page you should be redirected to ADFS box asking for a credentials on a browser pop-up : - To access IDP initiated SSO access the following link : https://<ADFS_hostname>/adfs/ls/idpinitiatedsignon.aspx

Below are the steps to configure SAML 2.0 SSO using ADFS as Identity Provider and WLS as Service Provider. In this example I am using ADFS 2.0 on Windows Server 2008R2. Let's have a look at the ADFS IDP...

Weblogic Security

X509 Certificate Revocation Checking using OCSP (Online Certificate Status Protocol) in Weblogic Server

In this post we will see how to configure OCSP based certificate revocation check in Weblogic Server : - First we need to create a self-signed certificate and get it signed from an internal CA (created using openssl) - Then create another self-signed certificate and get it signed from the same CA. Now lets revoke this certificate. - Establish a two-way SSL communication between browser and WLS. - Configure WLS to enable OCSP (Online Certificate Status Protocol) check. - Connect to WLS using valid and revoked certificate and see the difference. Step 1 : - Install OpenSSL and modify the openssl.cfg file as follows :  authorityInfoAccess = OCSP;URI: http://host:port Download sample openssl.cfg file HERE..!! NOTE : Right Click on the above hyperlink and click on "Save Link As" - Now download the file and rename its extension to .zip.  Setup your shell/cmd prompt to use the openssl.cfg file : Command : export OPENSSL_CONF=/tmp/package-root/usr/local/ssl/openssl.cnf Step 2 : Create an Internal CA Command :  ./openssl req -nodes -new -x509 -keyout cakey.pem -out cacert.pem -days 3650 Step 3 : Create a certificate and get it signed by internal CA. (say Valid certificate) Command :  ./openssl req -nodes -newkey rsa:2048 -keyout newkey.pem -out newreq.pem -days 3650 ./openssl ca -policy policy_anything -out validcert.pem -infiles newreq.pem Step 4 : Create a certificate and get it signed by internal CA (say Revoked certificate). Command : ./openssl req -nodes -newkey rsa:2048 -keyout newkeyFake.pem -out newreqFake.pem -days 3650 ./openssl ca -policy policy_anything -out revokecert.pem -infiles newreqFake.pem Lets revoke this certificate now : Command : ./openssl ca -revoke revokecert.pem  Create two .p12 keystore (valid keystore and revoked keystore) using the following command, this file will be used to configure certificates/keystore on the browser :  Command : ./openssl pkcs12 -export -in validcert.pem -inkey newkey.pem -out valid.p12 -name "valid"   ./openssl pkcs12 -export -in revokecert.pem -inkey newkeyFake.pem -out revoked.p12 -name "revoked"  Step 5: Start your OCSP server. Command : ./openssl ocsp -index index.txt -CA cacert.pem -rsigner cacert.pem -rkey cakey.pem -port 8888  Step 6: Configure Weblogic to enable OCSP based certificate Revocation Check. Step 7 : - Enable SSL (Demo Identity and Demo Trust will be configured by default) on Weblogic and enable Two-WAY SSL (client-cert requested and enforced) Login to console -> +Environment -> Servers -> AdminServer -> General -> SSL Listen port Enabled (check) Login to console -> +Environment -> Servers -> AdminServer -> SSL -> +Advanced -> Two Way Client Cert Behavior -> select "Client Certs Requested and Enforced " from the drop down menu. - Enable Certificate Revocation Debugs : Login to console -> +Environment -> Servers -> AdminServer ->Debug -> +weblogic -> +security -> certrevocationchecking (enable) - Make sure you increase the logging severity to DEBUG : Login to console -> +Environment -> Servers -> AdminServer ->Logging  -> +Advanced -> Log file : Severity level : Debug   Standard out : Severity level : Debug Step 8 : Configure a certificate signed by internal CA on your browser and access Weblogic console. 1) First configure the valid .p12 keystore --> access the console over SSL and check the Weblogic logs 2) Now delete the valid certificate.keystore from IE and configure Revoked .p12 keystore --> access the console over SSL and check the Weblogic logs  NOTE :  - After successfully configuring Two-Way SSL on Weblogic Admin Server and browser (IE) --> Access WLS console over https. You should see the following : NOTE : - Configure a valid .p12 keystore on IE and access the Weblogic console on Https, you will see the following logging in out file :  <Aug 26, 2015 1:36:50 AM IST> <Debug> <CertRevocCheck> <BEA-000000> <The revocation status of certificate CN=Valid-Certificate, O=Valid, L=Bang, ST=Kar, C=IN is:Status=NOT REVOKEDSource=OCSPSubject="CN=Valid-Certificate,O=Valid,L=Bang,ST=Kar,C=IN"Issuer="CN=Internal-CA,OU=Weblogic,O=Oracle,L=Bangalore,ST=Karnataka,C=IN"SerialNumber=1StatusValid=Tue 25 Aug 2015 16:08:39.000 +0530StatusExpires=nullNonceIgnored=falseRevocationTime=nullReasonCode=nullFlags=0ProducedAt=Tue 25 Aug 2015 16:08:39.000 +0530.><Aug 26, 2015 1:36:50 AM IST> <Info> <Security> <BEA-090914> <Certificate revocation status:Status=NOT REVOKEDSource=OCSPSubject="CN=Valid-Certificate,O=Valid,L=Bang,ST=Kar,C=IN"Issuer="CN=Internal-CA,OU=Weblogic,O=Oracle,L=Bangalore,ST=Karnataka,C=IN"SerialNumber=1StatusValid=Tue 25 Aug 2015 16:08:39.000 +0530StatusExpires=nullNonceIgnored=falseRevocationTime=nullReasonCode=nullFlags=0ProducedAt=Tue 25 Aug 2015 16:08:39.000 +0530> NOTE : - Configure a revoked .p12 keystore on IE and access the Weblogic console on Https, you will see the following logging in out file :  <Aug 26, 2015 1:31:51 AM IST> <Debug> <CertRevocCheck> <BEA-000000> <The revocation status of certificate CN=Revoked-Certificate, OU=Bad, O=Revoked, L=Fake, ST=Fake, C=PP is:Status=REVOKEDSource=OCSPSubject="CN=Revoked-Certificate,OU=Bad,O=Revoked,L=Fake,ST=Fake,C=PP"Issuer="CN=Internal-CA,OU=Weblogic,O=Oracle,L=Bangalore,ST=Karnataka,C=IN"SerialNumber=2StatusValid=Tue 25 Aug 2015 16:03:41.000 +0530StatusExpires=nullNonceIgnored=falseRevocationTime=Tue 25 Aug 2015 15:13:53.000 +0530ReasonCode=-1Flags=0ProducedAt=Tue 25 Aug 2015 16:03:41.000 +0530.><Aug 26, 2015 1:31:51 AM IST> <Info> <Security> <BEA-090914> <Certificate revocation status:Status=REVOKEDSource=OCSPSubject="CN=Revoked-Certificate,OU=Bad,O=Revoked,L=Fake,ST=Fake,C=PP"Issuer="CN=Internal-CA,OU=Weblogic,O=Oracle,L=Bangalore,ST=Karnataka,C=IN"SerialNumber=2StatusValid=Tue 25 Aug 2015 16:03:41.000 +0530StatusExpires=nullNonceIgnored=falseRevocationTime=Tue 25 Aug 2015 15:13:53.000 +0530ReasonCode=-1Flags=0ProducedAt=Tue 25 Aug 2015 16:03:41.000 +0530> NOTE : When your ocsp server is down you will see the following in Weblogic Server logs and both valid and revoked keystore will be accepted by Weblogic.   <Aug 26, 2015 1:40:19 AM IST> <Debug> <CertRevocCheck> <BEA-000000> <Exception while checking revocation status using OCSP.com.rsa.certj.spi.revocation.CertStatusException: com.rsa.certj.spi.pki.PKIException: OCSP.SendOCSPRequest: Tried all: '1' addresses, but could not connect over HTTP to server: 'celbealnx9.us.oracle.com', port: '8888'        at com.rsa.certj.provider.revocation.ocsp.OCSP$Implementation.checkCertRevocations(OCSP.java:705)        at com.rsa.certj.provider.revocation.ocsp.OCSP$Implementation.checkCertRevocation(OCSP.java:592)        at com.rsa.certj.CertJ.checkCertRevocation(CertJ.java:1270)        at weblogic.security.pki.revocation.common.DefaultOcspChecker.checkCertRevocation(DefaultOcspChecker.java:737)        at weblogic.security.pki.revocation.common.DefaultOcspChecker.getRemoteStatus(DefaultOcspChecker.java:133)        at weblogic.security.pki.revocation.common.OcspChecker.getCertRevocStatus(OcspChecker.java:93)        at weblogic.security.pki.revocation.common.RevocationCertPathChecker.runThruMethods(RevocationCertPathChecker.java:279)        at weblogic.security.pki.revocation.common.RevocationCertPathChecker.check(RevocationCertPathChecker.java:185)  NOTE : -  In the above example I am using browser as SSL client to demonstrate OCSP feature in WLS. - But you can use any Java standalone client to connect to Weblogic and initiate a two-way SSL to demonstrate the above behavior  Example : java -Djavax.net.ssl.keyStoreType=jks -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.keyStore=valid.jks -Djavax.net.ssl.trustStore=trust.jks -Djavax.net.debug=ssl  -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStorePassword=password -cp . TwoWaySSLClient

In this post we will see how to configure OCSP based certificate revocation check in Weblogic Server : - First we need to create a self-signed certificate and get it signed from an internal CA (created...

Steps to create a self-signed certificate using OpenSSL

Below are the steps to create a self-signed certificate using OpenSSL : STEP 1 : Create a private key and public certificate using the following command : Command : openssl req -newkey rsa:2048 -x509 -keyout cakey.pem -out cacert.pem -days 3650  In the above command : - If you add "-nodes" then your private key will not be encrypted. - cakey.pem is the private key - cacert.pem is the public certificate STEP 2 : Use the following java utility to create a JKS keystore :  Command : java utils.ImportPrivateKey -keystore identity.jks -storepass password -keyfilepass privatepassword -certfile cacert.pem -keyfile cakey.pem -alias mykey  Alternatively, you can use the following commands to create a PKCS12 / JKS file :  STEP 2a : Create a PKCS12 keystore : Command : openssl pkcs12 -export -in cacert.pem -inkey cakey.pem -out identity.p12 -name "mykey"  In the above command : - "-name" is the alias of the private key entry in keystore.  STEP 2b : Now convert the PKCS12 keystore to JKS keytstore using keytool command :  Command : keytool -importkeystore -destkeystore identity.jks -deststorepass password -srckeystore identity.p12 -srcstoretype PKCS12 -srcstorepass password  STEP 3 : Create a trust keystore using the following command : Command : keytool -import -file cacert.pem -keystore trust.jks -storepass password <Additional Info> - To view the public certificate :  openssl x509 -in cacert.pem -noout -text - To concatenate the private key and public certificate into a pem file (which is required for many web-servers ) :  cat cakey.pem cacert.pem > server.pem  

Below are the steps to create a self-signed certificate using OpenSSL : STEP 1 : Create a private key and public certificate using the following command : Command : openssl req -newkey rsa:2048...

Weblogic Security

Steps to configure Kerberos / SPNEGO / NTLM authentication with Weblogic Server running on IBM JDK (AIX machine)

AD Machine (Windows Server 2012 R2) used in this configuration is : slads.slab.bea.com  WLS 10.3.6 is installed on AIX 6.1 : celbealnx4.us.oracle.com kerberos_aix is the user created in AD which will represent the weblogic server machine.  *****************************  Step 1 : - Create a new user say, " kerberos_aix " on AD which will represent your Weblogic server instance.  Note : - The account type should be "User", not a "Computer" in the AD. - Check password never expires option for the user.  - DES encryption type is disabled by default on Windows 2008 AD and above and hence do not check this option for the user. - If your AD is on Windows 2003, enable DES encyption type for your user --> after enabling this option make sure you reset the password for this user. - If you want to use AES encryption type make sure you check " This account supports AES 128 bit encryption "/ "This account supports AES 256 bit encryption " in the username --> properties --> Account Options field. - If you want to use  AES256-SHA1 cipher strength then, You need to download and install this bundle which provides "unlimited strength" policy files which contain no restrictions on cryptographic strengths. * For IBM JDK 6 and above: Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from :  https://www-01.ibm.com/marketing/iwm/iwm/web/preLogin.do?source=jcesdk < Additional Info > http://goo.gl/XZRasJ Step 2 : Create a krb5.conf file.  Syntax : ***** [libdefaults]default_realm = <Identifies the default realm. Set its value to your Kerberos realm - all caps>default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5permitted_enctypes =  aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5ticket_lifetime = 600kdc_timesync = 1ccache_type = 4 [realms]<Your Kerberos realm – remember all caps> = {kdc = <IP address of the KDC/AD server>admin_server = <FQDN - host name of the KDC/AD server OR  IP address of KDC/AD server>default_domain = <Windows domain name in caps>}[domain_realm].<DNS domain name suffix, starting with .> = <Your Kerberos realm – remember all caps><DNS domain name suffix.> = <Your Kerberos realm – remember all caps> [appdefaults]autologin = trueforward = trueforwardable = trueencrypt = true  *****  Note : * This file has to be created on the machine where Weblogic Server is installed. In this case it is present in AIX 6.1 machine. * In AIX machine, the default location is /etc/krb5/krb5.conf.* It is always good to specify only the encryption type that is needed in default_tkt_enctypes and default_tgs_enctypes. For example rc4-hmac in this case. (have a look at the above screenshot).  DOWNLOAD A SAMPLE OF KRB5.CONF Step 3 : Lets check if your AIX box is able to communicate with the KDC using the information provided in the krb5.conf  : Command : kinit kerberos_aix OR kinit kerberos_aix @<REALM> Step 4 : ( Run the following commands on AD machine ).  Lets make sure that there are no duplicate SPNs in your AD box and then add an SPN to " kerberos_aix" user : Syntax : setspn -S HTTP/<wls-server-name>@<REALM-NAME> <account_name>  Command :  setspn -S HTTP/celbeaaix2.us.oracle.com@SLAB.BEA.COM kerberos_aix Now lets create a keytab file : Syntax : ktpass –princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> –pass password -crypto all -kvno 0 -ptype KRB5_NT_PRINCIPAL –out <keytab-file-name> Command :  ktpass -princ HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM -mapuser wlsclient -pass Weblogic1 -crypto Rc4-HMAC-NT -kvno 0 -ptype KRB5_NT_PRINCIPAL -out kerberos_aix_rc4.keytab Note : * Running ktpass will modify the account details, changing the user login name to match the service principal name – note that this is a consequence of running the above command, not something you need to do manually * Click on the user " kerberos_aix " properties to see the change. * Now copy the keytab file generated (kerberos_aix_rc4.keytab) to machine where Weblogic Server is installed.  * If you are using Windows 2003 AD then use the following command : ktpass –princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> –pass password -crypto DES-CBC-CRC -ptype KRB5_NT_PRINCIPAL –out <keytab-file-name> * In the above command you can use "-crpto all" but there are few IBM JDK bugs which cause the JASS config to always look into the first encryption type available in the keytab and will fail saying it was not able to find RC4-HMAC. This is fixed in the latest versions of JDK, however it is safe to create a keytab containing only the required encryption type " -crypto RC4-HMAC-NT ". Step 5 : After copying the keytab file to the machine where Weblogic Server is installed, run the klist command to see the contents of the keytab file. Syntax : klist -k <keytab> Command : klist -e -k kerberos_aix_rc4.keytab If your principal was created properly, you should be able to request a TGT (ticket Granting Ticket) from Kerberos using that principal. If the keytab file was generated properly, then you should be able to use this file instead of the password of your account. kinit tests both simultaneously.  Syntax :  kinit –k –t <keytab-file> <account-name> Command :  kinit -k -t kerberos_aix_rc4.keytab HTTP/celbeaaix2.us.oracle.com@SLAB.BEA.COM Output : Done! New ticket is stored in cache file /u01/CR-root/krb5cc_slcruser Now lets enable few debugs to get a detailed output : Command :  java -Dcom.ibm.security.jgss.debug=all -Dcom.ibm.security.krb5.Krb5Debug=all com.ibm.security.krb5.internal.tools.Kinit -k -t kerberos_aix_rc4.keytab HTTP/celbeaaix2.us.oracle.com@SLAB.BEA.COM Note : *  When you lock and unlock your computer, you are causing Windows to request new Kerberos tickets. Another way to force Windows to request new Kerberos tickets is to run " klist purge " from the command prompt. This explicitly asks Windows to dump your currently Kerberos tickets and thus, request new ones. Step 6 : Now, lets create a JAAS config file, that will be used by Weblogic server : Create a file called " krb5Login.conf " and place it in the Weblogic Server domain directory :  Syntax : Have a look at the following doc for list of supported and unsupported parameters in JAAS config file : http://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/jgssDocs/jaas_login_user.html Example :  com.ibm.security.jgss.initiate {com.ibm.security.auth.module.Krb5LoginModule requiredcredsType=initiatordebug=true;};com.ibm.security.jgss.krb5.accept {com.ibm.security.auth.module.Krb5LoginModule requiredprincipal="HTTP/celbeaaix2.us.oracle.com@SLAB.BEA.COM"useKeytab="file:/refresh/CR-root/Oracle/Middleware3/user_projects/domains/kerberos_AIX/kerberos_aix_rc4.keytab"credsType=acceptordebug=true;}; DOWNLOAD A SAMPLE OF KRB5LOGIN.CONF Step 7 :  Now lets add few -D parameters to Weblogic Server startup script :  -Djava.security.auth.login.config=krb5Login.conf  -Djavax.security.auth.useSubjectCredsOnly=false  -Djava.security.krb5.conf=/etc/krb5/krb5.conf  -Dweblogic.security.enableNegotiate=true DEBUG Flags :  -Dcom.ibm.security.jgss.debug=all  -Djava.security.debug=configfile,configparser,gssloginconfig -Dcom.ibm.security.krb5.Krb5Debug=all  OPTIONAL Flags :  -Djava.security.krb5.realm=<realm> -Djava.security.krb5.kdc=<kdc> Example :  JAVA_OPTIONS="-Dcom.ibm.security.jgss.debug=all -Djava.security.auth.login.config=/u01/CR-root/Oracle/Middleware3/user_projects/domains/kerberos_AIX/krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.debug=configfile,configparser,gssloginconfig -Dcom.ibm.security.krb5.Krb5Debug=all -Dweblogic.security.enableNegotiate=true -Djava.security.krb5.conf=/etc/krb5/krb5.conf ${JAVA_OPTIONS}" export JAVA_OPTIONS Step 8 : Login to weblogic console and configure Active Directory provider. Change the control flags of all the providers to " Optional ". If you have set control flag as sufficient then reorder the providers and make sure Active Directory providers is the first provider in the list.  Step 9 : Now, create a " NegotiateIdentityAsserter "  Step 10 : Setup your browser for Kerberos Authentication. * No special configuration needed for Chrome Browser. * For Mozilla Firefox browser : 1. Start Firefox. 2. Enter about:config in the Location Bar. 3. Enter the filter string network.negotiate. 4. Double click on network.negotitate-auth.delegation-uris  and enter " http://,https:// " 5. Double click on network.negotitate-auth.trusted-uris and enter " http://,https:// "  * For Internet Explorer : Configure Local Intranet Domains    1. In Internet Explorer, select Tools > Internet Options.    2. Select the Security tab.    3. Select Local intranet and click Sites.    4. In the Local intranet popup, ensure that the Include all sites that bypass the proxy server and Include all local (intranet) sites not listed in other zones options are checked.    5. Click Advanced.    6. In the Local intranet (Advanced) dialog box, add all relative domain names that will be used for Oracle WebLogic Server instances participating in the SSO configuration (for example, myhost.example.com) and click OK. Configure Intranet Authentication    1. Select Tools > Internet Options.    2. Select the Security tab.    3. Select Local intranet and click Custom Level... .    4. In the Security Settings dialog box, scroll to the User Authentication section.    5. Select Automatic logon only in Intranet zone. This option prevents users from having to re-enter logon credentials, which is a key piece to this solution.    6. Click OK. Now, when you access your Weblogic Admin Console, you should be able to login to it without entering a username / password.

AD Machine (Windows Server 2012 R2) used in this configuration is : slads.slab.bea.com  WLS 10.3.6 is installed on AIX 6.1 : celbealnx4.us.oracle.com kerberos_aix is the user created in AD which will...

Weblogic Security

How to configure a Custom IDP login page for SAML SSO in Weblogic

Configure SAML SSO with Weblogic as mentioned in the following blog post : Link :  https://blogs.oracle.com/blogbypuneeth/entry/steps_to_configure_saml_21 Lets test the IDP initiated SSO first :  In the source application if you have an <auth-method>  set to form then you would get a custom form login page. web.xml :   <login-config> <auth-method>CLIENT-CERT,FORM</auth-method> <realm-name>myrealm</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/fail_login.htm</form-error-page> </form-login-config>    </login-config> Example : When you try an SP initiated SSO, i.e you access a destination application - you get a basic challenge (from IDP) asking for the username and password.  This basic challenge is from the default saml2.war application located in " <Oracle_Home>/wlserver/server/lib " web.xml file is as follows :   <login-config>      <auth-method>BASIC_PLAIN</auth-method>  </login-config> You can esit the web.xml file of the default saml2.war application and change the auth-method to FORM to get a form login. However, Oracle doesnot recommend editing the default saml2.war file. The goal of this document is to configure a custom login page instead of a basic challenge. Below are the steps : - Download the sample CustomLogin application from the link below : CustomLogin.war (DOWNLOAD) - Deploy this application in your IDP domain.  - Login to Weblogic console on IDP domain -> <server> -> Federation Services -> SAML 2.0 Identity Provider -> Login Customized ( enable ) Login URL:  /CustomLogin/saml2login - Now test an SP initiated SSO, you should see a CustomLogin page ( FORM page ) from the CustomLogin.war application.

Configure SAML SSO with Weblogic as mentioned in the following blog post : Link :  https://blogs.oracle.com/blogbypuneeth/entry/steps_to_configure_saml_21 Lets test the IDP initiated SSO first :  In the...

Weblogic Security

Steps to create a .jks keystore from .pfx file

Windows Server makes use of the pfx file to store the public and private key files. Consider a scenario where in you are exporting a pfx file from IIS server, and you need to use the same in Weblogic Server. When you are exporting a PFX file make sure you select the following option : " export the private key and include all certificates in certificate path if possible. "  So, now your PFX file contains the private key along with the other public certificates. You need to convert the pfx file to .jks to use with Weblogic Server ( recommended keystore format for Weblogic is jks ) -  Step 1 : First convert the .pfx file to .pem using the following command : Using OpenSSL : openssl pkcs12 -in mypfxfile.pfx -out frompfx.pem -nodes Step 2 : Now, open the pem file that got generated ( frompfx.pem ) in notepad ( preferably Notepad++ ) : Bag Attributes     Microsoft Local Key set: <No Values>     localKeyID: 01 00 00 00      Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider     friendlyName: xxxxxxxxxx Key Attributes     X509v3 Key Usage: 10  -----BEGIN PRIVATE KEY----- KQr5BUJClayE5sGk8psPIlpKOH77L/KM44y/5V5eZggScuL1n5TF3zWdxmVCfXyO 6eeMnOraiushpdjqEhdZ81Ovp7WW2P15C5HhRboDTffyIRPymlDQ7z6iYwcJehdC . . . Tt+Xd8OA4YxGGMqdTvtQM0CMrGAuK87Rn2DenqcU+fPqyQRJYYAfgPsoRp16Ze3U uENA/5u8wQ3jZGyoAwT6RQ== -----END PRIVATE KEY----- Bag Attributes     localKeyID: 01 00 00 00      friendlyName: xxxxxxxxxx subject=/C=IN/O=WLS/OU=Oracle/OU=WLS/CN=xxxxxxxxxx issuer=/C=IN/O=WLS -----BEGIN CERTIFICATE----- UzEYMBYGA1UEChMPQ2l0aWdyb3VwIFFBQ0ExMB4XDTE0MDYwMzE4NDgyN1oXDTE2 MDYwMzE5MTgyN1owZTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NpdGlncm91cCBR . . . u020Yq/ZURDS5zuUwrTcQ/wEIEb3yPwsg2Ce5kZNyyRmei1tLVqK9Vjxg5JYF0fF DClwSQ== -----END CERTIFICATE----- Bag Attributes     localKeyID: 01 00 00 00      friendlyName: xxxxxxxxxxx subject=/C=IN/O=WLS issuer=/C=IN/O=WLS -----BEGIN CERTIFICATE----- REVWLk5BTS5OU1JPT1QuTkVUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAnNW8FRdS0wTsaCkK+QVCQpWshObBpPKbDyJaSjh++y/yjOOMv+VeXmYIEnLi . . . M/qKGqnM4BI2XD4wCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWOC4xAwID FX6HOFiP== -----END CERTIFICATE----- Step 3 : The above example contains a private key entry and two certificates, lets create two pem files ( private and public ) as shown below : -----BEGIN PRIVATE KEY----- KQr5BUJClayE5sGk8psPIlpKOH77L/KM44y/5V5eZggScuL1n5TF3zWdxmVCfXyO 6eeMnOraiushpdjqEhdZ81Ovp7WW2P15C5HhRboDTffyIRPymlDQ7z6iYwcJehdC . . . Tt+Xd8OA4YxGGMqdTvtQM0CMrGAuK87Rn2DenqcU+fPqyQRJYYAfgPsoRp16Ze3U uENA/5u8wQ3jZGyoAwT6RQ== -----END PRIVATE KEY----- Save this to a file called key.pem -----BEGIN CERTIFICATE----- UzEYMBYGA1UEChMPQ2l0aWdyb3VwIFFBQ0ExMB4XDTE0MDYwMzE4NDgyN1oXDTE2 MDYwMzE5MTgyN1owZTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NpdGlncm91cCBR . . . u020Yq/ZURDS5zuUwrTcQ/wEIEb3yPwsg2Ce5kZNyyRmei1tLVqK9Vjxg5JYF0fF DClwSQ== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- REVWLk5BTS5OU1JPT1QuTkVUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAnNW8FRdS0wTsaCkK+QVCQpWshObBpPKbDyJaSjh++y/yjOOMv+VeXmYIEnLi . . . M/qKGqnM4BI2XD4wCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWOC4xAwID FX6HOFiP== -----END CERTIFICATE----- Save this to a file and name it certs.pem Step 4 : Now, convert private key file ( key.pem ) to key.der : - Open a cmd prompt and go to <domain_home>/bin folder and run "setDomainEnv.sh/setDomainEnv.cmd" - Now run the following comand :        java utils.pem2der key.pem This will create a key.der file. Step 5 : Now use the following command to import the root and public certificates to a jks identity keystore : java utils.ImportPrivateKey -keystore identity.jks -storepass password -keyfilepass password -certfile certs.pem -keyfile key.der -alias mykey Step 6 : Now, list the keystore and check the certificates and the private key entry, you can also validate the certificate chain : keytool -list -v -keystore identity.jks -storepass password   (To list the contents of a keystore) java utils.ValidateCertChain -jks mykey identity.jks   (To validate a certificate chain) OR Using Keytool ( JDK 6 and above ) : Syntax : keytool -importkeystore -srckeystore <source_keystoreFile> -srcstoretype PKCS12 -destkeystore <destination_keystoreFile>  -deststoretype JKS -srcstorepass mysecret -deststorepass mysecret -srcalias myalias -destalias myalias -srckeypass mykeypass -destkeypass mykeypass -noprompt Example :  keytool -importkeystore -srckeystore mypfxfile.pfx -srcstoretype pkcs12 -destkeystore identity.jks -deststoretype JKS

Windows Server makes use of the pfx file to store the public and private key files. Consider a scenario where in you are exporting a pfx file from IIS server, and you need to use the same in Weblogic...

Weblogic Security

Steps to configure Custom Identity and Custom Trust with Weblogic Server

Below are the steps to configure Custom Identity and Custom Trust with Weblogic Server : Step 1 : Login to Weblogic Admin console --> Environment --> Servers --> < server_name_where_ssl_has_to_be_configured > --> Configuration -> General --> SSL Listen Port Enabled ( Check ) Note : The default SSL Listen Port would be 7002, change it if required.  Step 2 : Click on Keystores tab under " Configuration " tab : Step 2a : Click on the drop down menu next to Keystores and select " Custom Identity and Custom Trust "  Step 2b : Now fill in the following information : ---Identity---   Custom Identity Keystore : < location_of_identity_keystore_that_you_have_created> NOTE : By default WLS will look for this keystore file in domain_home location.  Custom Identity Keystore Type : jks  Custom Identity Keystore Passphrase: < This_would_be_your_storepass >  ---Trust---  Custom Trust Keystore : < location_of_trust_keystore_that_you_have_created> NOTE : By default WLS will look for this keystore file in domain_home location.  Custom Trust Keystore Type : jks  Custom Trust Keystore Passphrase: < This_would_be_your_storepass > Step 2c : Now save the changes and click on " SSL " tab : Private Key Alias: < This_would_be_your_certificate_alias > Private Key Passphrase: < This_would_be_your_keypass > Step 3 : Save the changes and click on the " >Advanced " field under the " SSL " tab :   Set the " Hostname Verification: " to None ( from the drop down menu ). NOTE : We need to select the hostname verification as none if the CN of the certificate is not the same as the hostname of the machine where WLS is installed.   Now access your Weblogic Admin console over https URL :  " https://localhost:7002/console " NOTE :  To get rid of the above warnings create a csr and get it signed from a third party CA like GoDaddy, Verisign, Thawte etc and configure Custom Identity and Custom Trust in Weblogic Server. Steps to create a csr and get it signed from a third party CA : Link : https://blogs.oracle.com/blogbypuneeth/entry/steps_to_create_a_csr

Below are the steps to configure Custom Identity and Custom Trust with Weblogic Server : Step 1 : Login to Weblogic Admin console --> Environment --> Servers --> <...

Weblogic Security

Steps to configure Multiple AD Kerberos Domain with Weblogic Server

Multi Domain AD - Kerberos with WLS : ____________________________________ In this example I am using two AD domains : UP.COM and DOWN.COM I have configured a forest trust between these two AD boxes. I have created a user " up_user " in UP.COM and " down_user " in DOWN.COM. The two users I created above will represent the Weblogic Server Machine. I will now create user " test_up " in UP.COM and " test_down " in DOWN.COM I will use test_up and test_down users to check if Forest Trust is working fine. Note : The steps below are not a part of multi AD domain Kerberos configuration. This is just to test if Forest Trust is working fine. Make both the users " test_up " and " test_down " member of " Administrator " group and " Remote Desktop Users " group, so that I can use Remote Desktop Client to login with these users. Now connect to the DOWN.COM box using RDC, login with UP/test_up You should be able to login to DOWN.COM domain successfully. Try the same with test_down user and UP.COM domain. If you are able to login from a user in one domain to another domain then Forest Trust is configured properly. Summarizing the above : AD Machine 1 : celbeavm13.us.oracle.comAD Domain 1 : UP.COM ( Windows 2008 R2 )User that represents WLS : up_userUser in UP.COM domain : test_up AD Machine 2 : celbeavm14.us.oracle.comAD Domain 2 : DOWN.COM ( Windows 2008 R2 )User that represents WLS : down_userUser in DOWN.COM : test_down Weblogic Machine : SLKRBTRN6-03 ( Windows XP ) Weblogic Server 12.1.2 NOTE : How to configure the SSO for users falling into the multiple domains in Microsoft Active Directory (Doc ID 1470520.1) For older versions of WLS : - Apply Patch 14069872 and  - Add the following -D flag in WLS startup scripts : -Dweblogic.security.krb5.useGSSName=true. For WLS 12.1.1 and above :  - Add the following -D flag in WLS startup scripts : -Dweblogic.security.krb5.useGSSName=true. So lets get started...!! STEP 1 : Step 1a : - Create a new user say, " up_user " on AD 1 to represent Weblogic server instance. Step 1b : - Create a new user say, " down_user " on AD 2 to represent Weblogic server instance. STEP 2 : Create a krb5.ini file. Syntax : ******* [libdefaults] default_realm = <Identifies the default realm. Set its value to your Kerberos realm - all caps> default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 ticket_lifetime = 600 kdc_timesync = 1 ccache_type = 4 [realms] <Your Kerberos realm 1 – remember all caps> = { kdc = <IP address of the KDC/AD server 1>          //  (For Unix systems, you need to specify port 88, as in <IP-address>:88) admin_server = <FQDN - host name of the KDC/AD server 1> default_domain = <Windows domain name in caps> } <Your Kerberos realm 2 – remember all caps> = { kdc = <IP address of the KDC/AD server 2>          //  (For Unix systems, you need to specify port 88, as in <IP-address>:88) admin_server = <FQDN - host name of the KDC/AD server 2>} [domain_realm] .<DNS domain name suffix, starting with .> = .<Your Kerberos realm 1 – remember all caps> <DNS domain name suffix.> = <Your Kerberos realm 1 – remember all caps> .<DNS domain name suffix, starting with .> = .<Your Kerberos realm 2 – remember all caps> <DNS domain name suffix.> = <Your Kerberos realm 2 – remember all caps> [appdefaults] autologin = true forward = true forwardable = true encrypt = true ******* Example : [libdefaults]default_realm = UP.COMticket_lifetime = 600default_tkt_enctypes = RC4-HMACdefault_tgs_enctypes = RC4-HMAC[realms]UP.COM = {kdc = celbeavm13.us.oracle.comadmin_server = celbeavm13.us.oracle.com default_domain = UP.COM}DOWN.COM = {kdc = celbeavm14.us.oracle.comadmin_server = celbeavm14.us.oracle.com }[domain_realm].up.com = .UP.COMup.com = UP.COM.down.com = .DOWN.COMdown.com = DOWN.COM Note : * This file has to be created on the machine where Weblogic Server is installed. * If you have Weblogic Server installed on a Windows machines, create a file named krb5.ini / On Unix machines, the file is called krb5.conf instead of krb5.ini. * See the following default Kerberos configuration files and their locations:[Windows] The default location is c:\winnt\krb5.ini. Note: if the krb5.ini file is not located in the c:\winnt directory it might be located in c:\windows. [Linux] The default location is /etc/krb5.conf. [AIX] [HP-UX] [Solaris] On other Unix platforms, the default location is /etc/krb5/krb5.conf. STEP 3 : Step 3a : To check if the krb5.ini file you created is correct, run the following command : Command : kinit up_user OR kinit up_user@UP.COM Step 3b : To check if the krb5.ini file you created is correct, run the following command : Command : kinit down_user OR kinit down_user@DOWN.COM STEP 4 : Step 4a : Now create a keytab file ( Run the following commands on AD machine 1 ). Syntax : ktpass -princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> -pass password -crypto all -ptype KRB5_NT_PRINCIPAL -out <keytab-file-name> Command : ktpass -princ HTTP/SLKRBTRN6-03@UP.COM -mapuser UP\up_user -pass Weblogic1 -crypto all -kvno 0 -ptype KRB5_NT_PRINCIPAL -out wlsclientUP.keytab  Step 4b : ( Run the following commands on AD machine 2 ). Command : ktpass -princ HTTP/SLKRBTRN6-03@DOWN.COM -mapuser DOWN\down_user -pass Weblogic1 -crypto all -kvno 0 -ptype KRB5_NT_PRINCIPAL Instead of the above command, you can also use the following : Command : setspn -A HTTP/SLKRBTRN6-03@DOWN.COM DOWN\down_user I would suggest using ktpass as we can set the SPN and create a keytab and set the kvno number in ONE command. I have seen a BUG with JDK 1.6_22 with kvno, and I suggest you to use kvno 0 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6984764 You can set kvno using the ktpass command OR ktab -a <principal name> [<password>] [-n <kvno>] [-append]  NOTE : I am not using the argument -out in the above command ( step 4b ), because we dont need a keytab from both AD machines. Since there is a forest trust configured we just need a keytab file from one of the AD machines. * Running ktpass will modify the account details, changing the user login name to match the service principal name – note that this is a consequence of running the above command, not something you need to do manually * Click on the user " up_user " OR " down_user " --> properties to see the change. * Now copy the keytab file generated to the machine where Weblogic Server is installed. * If you are using Windows 2003 AD then use the following command : ktpass –princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> –pass password -crypto DES-CBC-CRC -ptype KRB5_NT_PRINCIPAL –out <keytab-file-name>  ____________________________ STEP 5 : After copying the keytab file to the machine where Weblogic Server is installed, run the klist command to see the contents of the keytab file. Syntax : klist -k <keytab> Command : klist -e -k wlsclientUP.keytab If your principal was created properly, you should be able to request a TGT (ticket Granting Ticket) from Kerberos using that principal. If the keytab file was generated properly, then you should be able to use this file instead of the password of your account. kinit tests both simultaneously. Syntax : kinit –k –t <keytab-file> <account-name> Command : kinit -J-Dsun.security.krb5.debug=true -k -t wlsclientUP.keytab HTTP/SLKRBTRN6-03@UP.COM OR java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit -k -t wlsclientUP.keytab HTTP/SLKRBTRN6-03@UP.COM Note : * In UNIX use the -V switch or else there wont be any output. ( kinit -V –k –t <keytab-file> <account-name> ) * The above debugs will not work in UNIX. It is specific to Windows. * When you lock and unlock your computer, you are causing Windows to request new Kerberos tickets. Another way to force Windows to request new Kerberos tickets is to run " klist purge " from the command prompt. This explicitly asks Windows to dump your currently Kerberos tickets and thus, request new ones.  ____________________________ STEP 6 : Now, lets configure Weblogic Server. Create a file called " krb5Login.conf " and place it in the Weblogic Server domain directory : Syntax : com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="<Service principal account>@<Kerberos realm>" useKeyTab=true keyTab=<keytab> storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="<Service principal account>@<Kerberos realm>" useKeyTab=true keyTab= <keytab> storeKey=true debug=true; }; -------------------------------------------- krb5Login.conf : com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/SLKRBTRN6-03@UP.COM"  useKeyTab=true keyTab=wlsclientUP.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/SLKRBTRN6-03@UP.COM"  useKeyTab=true keyTab=wlsclientUP.keytab  storeKey=true debug=true; }; Note : * If you are using JDK 1.5 then change the following line in the above file from " com.sun.security.jgss.krb5.accept " to " com.sun.security.jgss.accept ". i.e donot use krb5 in the accept and initiate method in the above file if you are using JDK 1.5. * Weblogic Server domain directory is the default location of keytab file and krb5Login.conf file. * Even an extra space in krb5Login.conf will cause errors while parsing the file. Below is a sample file, copy this file to your machine and only change the <UPN> ( "<Service principal account>@<Kerberos realm>" ) and <keytab> entries in it. DONOT give any extra spaces ..!!  ____________________________ STEP 7 : Now lets add few -D parameters to Weblogic Server startup script. -Djava.security.auth.login.config=krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -Djava.security.debug=configfile,configparser,gssloginconfig // This is the debug flag to check if the config files get parsed properly. -Dsun.security.krb5.debug=true < Additional -D parameters that can be set > -Djava.security.krb5.realm=<realm> -Djava.security.krb5.kdc=<kdc> -Dweblogic.security.krb5.useGSSName=true // Use this flag if you are configuring Kerberos with multiple AD domains, you also need to apply patch for Bug 14069872 ( fixed in 12.1.1 ) for this flag to work. // for IBM JDK you can use the following debug : -Dcom.ibm.security.jgss.debug=all  --  In windows edit " startWebLogic.cmd " file and add the following java options : set JAVA_OPTIONS=%JAVA_OPTIONS% -Djava.security.auth.login.config=krb5Login.conf –Djavax.security.auth.useSubjectCredsOnly=false –Dweblogic.security.enableNegotiate=true -Dsun.security.krb5.debug=true In UNIX edit " startWebLogic.sh " file and add the following java options : JAVA_OPTIONS=”${JAVA_OPTIONS} -Djava.security.auth.login.config=krb5Login.conf –Djavax.security.auth.useSubjectCredsOnly=false –Dweblogic.security.enableNegotiate=true -Dsun.security.krb5.debug=true”  ____________________________ STEP 8 : Login to weblogic console and configure Active Directory provider. Note : Say for example you have a " test " user in both the domains ( UP.COM and DOWN.COM ), then Weblogic will not know which domain the user belongs to. To help WLS understand which domain the user is coming from / to get the fully qualified Kerberos principal we need set the attribute : "weblogic.security.krb5.useGSSName" So now Weblogic will extract the user from token as " test@UP.COM ". Add the following system property for the WLS start scripts: -Dweblogic.security.krb5.useGSSName=true Once this is done, the ID retrieved from the kerberos token will be in the form of userid@domain Now make the following changes in console for AD provider : Login to WLS console --> security realms --> myrealm --> providers --> AD provider --> provider Specific : Change the "User From Name Filter" and the "User Name Attribute" parameters to use userPrincipalName Configure AD provider for both the AD domains.  NOTE :  * Another option is to create a single AD provider and connect it to a " Global Catalog ". Global Catalogs listen by default in port 3268. Check the following link for more information: http://technet.microsoft.com/en-us/library/cc728188%28v=ws.10%29.aspx AD administrator could be involved to help with the other properties for the AD Provider (User Base DN, Group Base DN, etc). Change the control flags of all the providers to " Optional ". If you have set control flag as sufficient then reorder the providers and make sure Active Directory providers is the first provider in the list. Apart from the parameter "-Dweblogic.security.krb5.useGSSName=true". We also need to apply a patch for BUG 12545239 ( Fixed in WLS 12.1.1 ).  ____________________________ STEP 9 : Now, create a " NegotiateIdentityAsserter "  ____________________________ STEP 10 : Setup your browser for Kerberos Authentication. * No special configuration needed for Chrome Browser. * For Mozilla Firefox browser : 1. Start Firefox. 2. Enter about:config in the Location Bar. 3. Enter the filter string network.negotiate. 4. Double click on network.negotitate-auth.delegation-uris and enter " http://,https:// " 5. Double click on network.negotitate-auth.trusted-uris and enter " http://,https:// " * For Internet Explorer : Configure Local Intranet Domains 1. In Internet Explorer, select Tools > Internet Options. 2. Select the Security tab. 3. Select Local intranet and click Sites. 4. In the Local intranet popup, ensure that the Include all sites that bypass the proxy server and Include all local (intranet) sites not listed in other zones options are checked. 5. Click Advanced. 6. In the Local intranet (Advanced) dialog box, add all relative domain names that will be used for Oracle WebLogic Server instances participating in the SSO configuration (for example, myhost.example.com) and click OK. Configure Intranet Authentication 1. Select Tools > Internet Options. 2. Select the Security tab. 3. Select Local intranet and click Custom Level... . 4. In the Security Settings dialog box, scroll to the User Authentication section. 5. Select Automatic logon only in Intranet zone. This option prevents users from having to re-enter logon credentials, which is a key piece to this solution. 6. Click OK. Verify Proxy Settings If you have a proxy server enabled: 1. Select Tools > Internet Options. 2. Select the Connections tab and click LAN Settings. 3. Verify that the proxy server address and port number are correct. 4. Click Advanced. 5. In the Proxy Settings dialog box, ensure that all desired domain names are entered in the Exceptions field. 6. Click OK to close the Proxy Settings dialog box. Now, when you access your Weblogic Admin Console, you should be able to login to it without entering a username / password. 

Multi Domain AD - Kerberos with WLS : ____________________________________ In this example I am using two AD domains : UP.COM and DOWN.COM I have configured a forest trust between these two AD boxes. I...

Weblogic Security

Steps to configure SAML 2.0 with Shibboleth ( deployed on WLS ) as IDP and Weblogic as SP.

In the example below we will see how to configure SAML 2.0 SSO using Shibboleth ( deployed on WLS ) as Identity Provider and Weblogic as Service provider. * I am using Shibboleth v2.3.8 as identity provider and Weblogic 10.3.6 as Service Provider  * and Active Directory for LDAP authentication in this example.  Step 1 : Create two domains in WLS 10.3.6, namely : " shibboleth-idp_domain " --> For Shibboleth IDP --> Admin server http port 7001 and https port 7002. " sp_domain " --> For WLS SP --> Admin server http port 8001 and https port 8002. Note : In this example I will be using the Weblogic console app for SAML SSO. If you want SAML SSO for any other application like analytics / BI / a custom app, which are deployed on Managed Servers, then make sure you give the port number of the Managed Servers in all the URLs during configuration. Step 2 : Download Shibboleth IDP from the following link : Link : http://shibboleth.net/downloads/identity-provider/2.3.8/shibboleth-identityprovider-2.3.8-bin.zip Step 3 : Unzip and Install Shibboleth. Unzip the downloaded Shibboleth software ( Unzip shibboleth-identityprovider-2.3.8-bin.zip to any location, say Desktop ) Open a cmd prompt and run the setDomainEnv.cmd command Now cd to the unzipped folder and run the following command :             install.sh   or   install.bat When you run the install.bat file, you would get an option to select the location where you want Shibboleth to be installed. Note : Give a path which does not have any spaces in between. Ex : Avoid using path like : C:\Program Files\shibboleth-idp In this example I have installed shibboleth in c:\shibboleth-idp. You would also get an option to create a self signed identity keystore. Note : You have to use a fully qualified DNS name for the host, ( Ex : FQDN like abcd.oracle.com  ) or else Shibboleth installation will fail  You can provide any password in the password field in cmd prompt. Note : The password you enter would be your storepass ( password of your keystore ), as well as the keypass ( password of your private key entry ). Step 4 : Configure Shibboleth as Identity Provider. To Configure Shibboleth as identity provider you need to edit the following Shibboleth config files and deploy a Shibboleth war file in Weblogic IDP domain. idp-metadata.xml login.config handler.xml relying-party.xml attribute-resolver.xml attribute-filter.xml Note : It is always good to take a backup of the original Shibboleth config files before editing them.  Lets edit the above files one after the other : Edit " C:\shibboleth-idp\metadata\idp-metadata.xml " and make the following changes : Search for " entityID " and " location " in idp-metadata.xml and fix all the URL's to point to the correct port number ( Port number of the server in WLS IDP domain where the shibboleth war file will be targeted ), in our case the port number is 7002 for domain : shibboleth-idp_domain ) .... .... <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entityID="https://test.oracle.com:7002/idp/shibboleth">  .... ....         <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://test.oracle.com:7002/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/>         <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://test.oracle.com:7002/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/>         <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>         <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>         <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://test.oracle.com:7002/idp/profile/Shibboleth/SSO"/>         <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://test.oracle.com:7002/idp/profile/SAML2/POST/SSO"/>         <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://test.oracle.com:7002/idp/profile/SAML2/POST-SimpleSign/SSO"/>         <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://test.oracle.com:7002/idp/profile/SAML2/Redirect/SSO"/> .... .... Comment the following lines in idp-metadata.xml : <!--         <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://test.oracle.com:7002/idp/profile/Shibboleth/SSO"/>  -->    2.   Edit " C:\shibboleth-idp\conf\login.config " and make the following changes : In this file you need to provide the values to connect to your LDAP. ( I am using ActiveDirectory in this example ) .... ....  ShibUserPassAuth {    edu.vt.middleware.ldap.jaas.LdapLoginModule required       ldapUrl="ldap://abc.in.oracle.com:389"       bindDn="test"       bindCredential="password"       ssl="false"       tls="false"       baseDn="CN=Users,DC=UP,DC=COM"       subtreeSearch="true"       userFilter="sAMAccountName={0}"; };  Note : - If you are connecting to OID then you can change the userFilter to  userFilter="uid={0}" - JAAS configuration files are loaded into the VM's runtime configuration. Because of this, changes to the login configuration file are NOT reloaded if you stop and restart the IdP web application. You MUST restart the entire web application server.    3.  Edit " C:\shibboleth-idp\conf\handler.xml " and make the following changes :  Un-comment Username/password login handler : .... .... <!--  Username/password login handler -->     <ph:LoginHandler xsi:type="ph:UsernamePassword"                   jaasConfigurationLocation="file://c:\shibboleth-idp/conf/login.config">        <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>    </ph:LoginHandler>........  Comment RemoteUser login handler : .... <!--     <ph:LoginHandler xsi:type="ph:RemoteUser">        <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>    </ph:LoginHandler> -->........ .... <!-- Login Handlers -->   4.   Edit " C:\shibboleth-idp\conf\relying-party.xml " and make the following changes : Correct the port number in the provider URL for DefaultRelyingParty element, and add a default authentication method. .... ....<rp:DefaultRelyingParty provider="https://test.oracle.com:7002/idp/shibboleth" defaultSigningCredentialRef="IdPCredential" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">........  In ProfileConfiguration for type="saml:SAML2SSOProfile" change the encryptAssertions from conditional to never. .... ....<rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true"                                  assertionLifetime="PT5M" assertionProxyCount="0"                                  signResponses="never" signAssertions="always"                                  encryptAssertions="never" encryptNameIds="never"/> ........   5.   Edit " C:\shibboleth-idp\conf\attribute-resolver.xml " and make the following changes :  Comment the AttributeDefinition ( in Name Identifier related attributes ) of type TransientId .... ....      <!-- Name Identifier related attributes --> <!--     <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId">         <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>         <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>     </resolver:AttributeDefinition> --> .... ....   Add  a new AttributeDefinition of type PrincipalName along with its AttributeEncoder .... ....  <resolver:AttributeDefinition id="principalId" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />    </resolver:AttributeDefinition>........    6.   Edit " C:\shibboleth-idp\metadata\attribute-filter.xml " and make the following changes :  Comment the section " Release the transient ID to anyone " ( i.e we need to comment the AttributeFilterPolicy for transient ID). .... ....       <!--  Release the transient ID to anyone --><!--        <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>        <afp:AttributeRule attributeID="transientId">        <afp:PermitValueRule xsi:type="basic:ANY"/>        </afp:AttributeRule>    </afp:AttributeFilterPolicy>-->.... ....   Add a new AttributeFilterPolicy for principal ID ( i.e we need to add a section " Release the principal ID to anyone " ) .... .... <!--  Release the principal ID to anyone -->     <afp:AttributeFilterPolicy id="releasePrincipalIdToAnyone">     <afp:PolicyRequirementRule xsi:type="basic:ANY"/>     <afp:AttributeRule attributeID="principalId">     <afp:PermitValueRule xsi:type="basic:ANY"/>     </afp:AttributeRule> </afp:AttributeFilterPolicy> ........  Step 5 : Deploy the Shibboleth idp.war file located in " C:\shibboleth-idp\war " onto your Weblogic Server in IDP domain.  Note : You have to modify the idp application to make it work with WLS in your environemnt. Click here to download a sample of modified idp.war file ( compiled with JDK 1.6 ). Please rename the idp.doc file to idp.zip and then unzip the file.  Note :  - If you have installed Shibboleth on a UNIX environment then you need to change the path for " internal.xml " and " service.xml " in the web.xml file of idp application. Eg : <context-param> <param-name>contextConfigLocation</param-name>         <param-value>file:<shibboleth_home>/conf/internal.xml; file:<shibboleth_home>/conf/service.xml;</param-value>     </context-param> To deploy this app successfully in WLS we need to endorse Xerces and Xalan  Copy all the jar files from endorsed directory of Shibboleth installation ( i.e C:\shibboleth-idp\lib\endorsed ) to <JAVA_HOME>/jre/lib/ext ( i.e C:\oracle\jdk\jre\lib\ext ) Login to Weblogic console and create a XML registry : Login to WLS console --> +services --> XML Registries --> new  Now add the following values :  Name: Apache Xerces/Xalan Registry SAX Parser Factory: org.apache.xerces.jaxp.SAXParserFactoryImplTransformer Factory: org.apache.xalan.processor.TransformerFactoryImpl Target / Deploy this XML Registry to Admin Server. ( For this example ) Restart the servers and deploy the modified idp.war file to Admin Server. Restart the server and check if application is in Active state. Note : To check if IDP is configured properly access the following URL : https://localhost:7002/idp/status You should see an output similar to the one in screenshot below : NOTE :  - If you see errors in your WLS logs then check if all the Shibboleth endorsed jars are added to your <JDK_HOME>/jre/lib/ext directory , Also check if you have made all the necessary changes in your IDP application and it is deployed successfully. - If there are no errors in WLS logs, then check the Shibboleth logs. Located in Ex : C:\shibboleth-idp\logs - To increase the logging severity to DEBUG in shibboleth, edit logging.xml file ( Located in Ex : C:\shibboleth-idp\conf ). ........ <!-- Logs IdP, but not OpenSAML, messages -->    <logger name="edu.internet2.middleware.shibboleth" level="DEBUG"/> ........  - The logging configuration for the IdP is located at $IDP_HOME/conf/logging.xml. This file is checked for changes every 10 minutes by default and is reloaded if changes have been made. This means a deployer can keep the logging level at WARN until a problem occurs and then change the logging to DEBUG to get more information if the problem persists, all without restarting the IdP.  Step 6 : Lets configure the Service provider now. ( Domain : sp_domain ) Create a SAML2IdentityAsserter in sp_domain. ( Ex : IdentityAsserter ). Login to Weblogic Console -> SecurityRealms -> myrealm -> providers/Authentication -> new -> SAML2IdentityAsserter Configure Admin Server as a SAML 2.0 Service Provider. Login to Weblogic Console -> +Environment -> servers -> AdminServer -> Federation Services -> SAML 2.0 Service Provider             Make the following changes : Enabled ( Check ) Always Sign Authentication Requests ( Check ) Preferred Binding: POST Default URL: http://<sp_domain_server_listenAddress>:<port>/console ( In our Ex : http://test.oracle.com:8001/console ) Save and Activate Changes. Configure SAML 2.0 Federation properties for Admin Server. Login to Weblogic Console -> +Environment -> servers -> AdminServer -> Federation Services -> SAML 2.0 General             Make the following changes : Replicated Cache Enabled ( Check ) Contact Person Given Name: Contact Person Surname: Contact Person Type: Contact Person Company: Contact Person Telephone Number: Contact Person Email Address: Organization Name: Organization URL: Published Site URL: This should in the format http://<sp_domain_server_listenAddress>:<port>/saml2 ( In our Ex : http://test.oracle.com:8001/saml2 ) Entity ID: ( Ex : myEntityID ) Single Sign-ON --> Single Sign-on Signing Key Alias: DemoIdentity Single Sign-on Signing Key Pass Phrase: DemoIdentityPassPhrase Confirm Single Sign-on Signing Key Pass Phrase: DemoIdentityPassPhrase Save and Activate Changes --> Restart your server.  Lets configure the SAML IdentityAsserter using IDP metadata Login to Weblogic Console -> SecurityRealms -> myrealm -> providers/Authentication -> IdentityAsserter ( This is the SAML2IdentityAsserter we created earlier ) -> Management -> new -> Create a SAML 2.0 Web Single Sign-on Identity Provider Partner                 Make the following changes : Name : WebSSO-IdP-Partner Path : < Path for the IDP metadata file ( In our Ex : C:\shibboleth-idp\metadata\idp-metadata.xml ). Now click on the newly created partner " WebSSO-IdP-Partner " and make the following changes :  Enabled ( check ) Description:  WebSSO-IdP-Partner Virtual User ( uncheck ) Redirect URIs: < URI's of protected page in your application > ( In our example it is : /console/* /console/*.jsp  Save and Activate changes. Make sure that you application cookie name is set to JSESSIONID, you need to check yours applications weblogic.xml file for the same. In our example we are using the Weblogic console as an application, so make the following changes : Login to Weblogic Console -> <sp_domain_name > -> Configuration -> General -> +Advanced -> Console Cookie Name: JSESSIONID Save and Activate changes --> Restart your server Lets export the SP metadata now. Login to Weblogic Console -> +Environment -> servers -> AdminServer -> Federation Services -> SAML 2.0 General -> Publish Meta Data Path : Give any path and a filename to store the SP metadata aml file. ( In our Eg : C:\shibboleth-idp\metadata\sp-metadata.xml ) Click OK Note : The path should include a file name with an xml extention or else the export of SP metadata will fail. Step 7 : Now lets configure Shibboleth Identity Provider to use the SP metadata. You need to add a reference to the sp-metadata file in relying-party.xml file ( Located in Ex : C:\shibboleth-idp\conf ) Edit C:\shibboleth-idp\conf\relying-party.xml file and make the following change : In the metadata configuration add a SP metadata configuration as follows : ........  <!-- Load the SP's own metadata.   -->         <metadata:MetadataProvider id="SPMD" xsi:type="metadata:FilesystemMetadataProvider"                                    metadataFile="c:\shibboleth-idp/metadata/sp-metadata.xml"                                    maxRefreshDelay="P1D" />.... ....  Restart both IDP and SP domains.  Step 8 : Create a Weblogic user in AD. Configure an Active Directory provider on both the domains.  Now restart the servers and test SSO. To test SAML SSO with Shibboleth : Access the Weblogic console on SP domain i.e http://test.oracle.com:8001/console This should redirect to a shibboleth login Page. Once you login you will be redirected back to the SP domain console page.

In the example below we will see how to configure SAML 2.0 SSO using Shibboleth ( deployed on WLS ) as Identity Provider and Weblogic as Service provider. * I am using Shibboleth v2.3.8 as identity...

Weblogic Security

Steps to create a csr ( certificate signing request ) using keytool and get it signed from an external CA ( Certificate Authority - Thawte )

Step 1 : Create a certficate pair using keytool genkeypair command  Command :  keytool -genkeypair -alias mykey -keyalg RSA -keysize 2048 -validity 365 -keypass privatepassword -keystore identity.jks -storepass password Step 2 : Now create a certificate signing request ( csr ) which has to be passed on to your external / third party CA ( Certificate Authority ). Command :  keytool -certreq -alias mykey -file certreq.pem -keystore identity.jks Note: - The above command Generates a Certificate Signing Request (CSR), using the PKCS#10 format. - A CSR is intended to be sent to a certificate authority (CA). The CA will authenticate the certificate requestor (usually off-line) and will return a certificate or certificate chain, used to replace the existing certificate chain (which initially consists of a self-signed certificate) in the keystore. - sigalg specifies the algorithm that should be used to sign the self-signed certificate; this algorithm must be compatible with keyalg. - The CSR is stored in the file certreq.pem. If no file is given, the CSR is output to stdout. - Researchers have successfully broken the MD5 algorithm and forged web server credentials. MD5 is no longer considered secure. US-CERT advisory 836068 (issued Dec 31, 2008) makes it plain: ‘Software developers, Certification Authorities, website owners, and users should avoid using the MD5 algorithm in any capacity. As previous research has demonstrated, it should be considered cryptographically broken and unsuitable for further use. So its better to use sigalg as SHA1withRSA Step 3 : Go to your third party CA website Eg : http://www.thawte.com/ I am using a Free SSL Trial here for testing.  Step 4 : Check your inbox for an email from Thawte. This email will contain your signed certificate , intermediate certificate and root certificate. Copy the contents of each certificate from email and save it as a pem file as shown below :  Step 5 : Now we need to import these certificates into identity.jks keystore - Import the intermediate certificate first --> then the root certificate --> and then the signedcert. Command : keytool -importcert -alias inter -file intermediate.pem -keystore identity.jks -storepass password Command : keytool -importcert -alias root -file root.pem -keystore identity.jks -storepass password  Command : keytool -importcert -alias mykey -file signedcert.pem -keystore identity.jks -storepass password  Note : - The intermediate and root certificate should have different alias name, but the signed certificate should be imported with the same alias that was used while creating a certificate pair. - After importing all three certificates you should see : " Certificate reply was installed in keystore " message. Step 6 : Now list the keystore and check if all the certificates are imported successfully. Command :  keytool -list -keystore identity.jks -storepass password To get a detailed out put : Command : keytool -list -v -keystore identity.jks -storepass password Note : Check for the following in the detailed output : Alias name: mykey  Entry type: PrivateKeyEntry Certificate chain length: 3 Step 7 : Run the following command to check if the certificate chain is valid. Syntax : java utils.ValidateCertChain -jks <alias> <identity_keystore>  Command :  java utils.ValidateCertChain -jks mykey identity.jks Step 8 : Lets create a trust keystore now. Command :  keytool -import -file intermediate.pem -alias inter -keystore trust.jks -storepass password Command : keytool -import -file root.pem -alias root -keystore trust.jks -storepass password Now that we have successfully created a third party CA signed Identity keystore and a Trust keystore, we can configure WLS to use it by configuring Custom Identity and Custom Trust. 

Step 1 : Create a certficate pair using keytool genkeypair command  Command :  keytool -genkeypair -alias mykey -keyalg RSA -keysize 2048 -validity 365 -keypass privatepassword -keystore identity.jks...

Weblogic Security

Steps to configure SAML 2.0 with Weblogic Server (using Oracle DB as a RDBMS security store)...

Note : - To setup SAML 2 with Weblogic 10.3.x we need to create a security database even before creating domain. - The RDBMS security store is required by the SAML 2.0 security providers in production environments so that the data they manage can be synchronized across all the WebLogic Server instances that share that data. - Note that Oracle does not recommend upgrading an existing domain in place to use the RDBMS security store. If you want to use the RDBMS security store, you should configure the RDBMS security store at the time of domain creation. If you have an existing domain with which you want to use the RDBMS security store, create the new domain and migrate your existing security realm to it. - For testing purpose you can use embedded LDAP instead of an external RDBMS store. Have a look at the following link : https://blogs.oracle.com/blogbypuneeth/entry/steps_to_configure_saml_2 Since we no longer have the pointbase database shipped along with Weblogic 10.3.6, I am using an Oracle database to configure RDBMS store. Prerequisite : Step 1 :  We need to create two security database – one for the source side domain and another for the destination side domain. To connect to your remote Database we can use the " Oracle Database Instant Client " application, which can be downloaded from : Link : http://www.oracle.com/technetwork/database/features/instant-client/index.html To connect to a remote Oracle Database I used the following command :   - cd C:\Users\puneeth\Desktop\instantclient_12_1  -  sqlplus "puneeth/puneeth@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=xx.xxx.xx.xx)(Port=1521))(CONNECT_DATA=(SID=oracle11g)))" -  Once it is connected successfully you would see the following prompt " SQL> " < Additional Info > Link : http://docs.oracle.com/html/B10131_02/post_install.htm - Now you need to create the database tables using the sample script ( rdbms_security_store_oracle.sql ) provided in your <wlserver_10.3>/server/lib - To run the script I used the following command : SQL> @rdbms_security_store_oracle.sql  Now we have created a table for RDBMS store using the Oracle user " puneeth " -- This can be used as an RDBMS store for one of the domains, say IDP. We have to create another table using a different user which can be used as an RDBMS store for the second domain, say SP. When creating a IDP domain use the user " puneeth " and while creating the SP domain use the second user say " puneeth1 " to connect to the RDBMS store. We need to run the same sample sql script  ( rdbms_security_store_oracle.sql ) by logging in as the " puneeth1 " user. In my case I did not have another DB user created, so I used the following command to create a new Oracle DB user : CREATE USER "USER" PROFILE "DEFAULT" IDENTIFIED BY "user" DEFAULT TABLESPACE "USERS" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK; GRANT UNLIMITED TABLESPACE TO "USER"; GRANT "CONNECT" TO "USER"; GRANT "RESOURCE" TO "USER"; Note : - I have used the user " puneeth " to connect to the DB for IDP domain and user " puneth1 " to connect to the DB for SP domain. - You should configure the RDBMS security store at the time of domain creation. - Do a test connection and make sure you are able to connect to the DB successfully. - Now create a domain namely " SAML2_IDP_Source_Domain " and " SAML2_SP_Destination_Domain " ----------------  Steps to configure SAML2 with Weblogic Server ( using RDMBS security store ) : Prerequisite : - In the following example I have created two domains " SAML2_IDP_Source_Domain " and " SAML2_SP_Destination_Domain " on Weblogic Server. - I have created self signed certificates and configured SSL on both the domains. - Source domain HTTP and HTTPS ports are 7001 and 7002 respectively. - Destination domain HTTP and HTTPS ports are 7003 and 7004 respectively. SAML Souce site configuration : - Create a " Credential Mapper " on Weblogic Source domain, i.e on the IDP end. - Login to Source domain - Weblogic console --> Click on ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> and add a ” SAML2CredentialMapper ” say ” SAML2_CredentialMapper ” as shown below : - Now click on the newly created SAML2CredentialMapper say ” SAML2_CredentialMapper ” and make the following changes : ">Issuer URI : http://www.souresite.com/saml Name Qualifier : sourcesite.com - Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Identity Provider ” and make the following changes : Enabled : check Preferred Binding : POST - Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes : Replicated Cache Enabled – Uncheck / Check Contact Person Given Name Contact Person Surname Contact Person Type Contact Person Company Contact Person Telephone Number Contact Person Email Address Organization Name Organization URL Published Site URL : http://<SourceSiteDNSName>:<PORT>/saml2 Entity ID : ( Source Domain name) Single Sign-on Signing Key Alias Single Sign-on Signing Key Pass Phrase Confirm Single Sign-on Signing Key Pass Phrase Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say idp_metadata.xml ). We need to copy this file to the destination domain later. Destination Site Configuration :  - Create an Identity Asserter on the destination domain, i.e SP end. - Login to Destination domain - Weblogic console --> Click on ” myrealm ” –> ” Providers ” –> ” Authentication ” –> new ” SAML2IdentityAsserter “ say ” SAML2_IdentityAsserter : Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Service Provider ” and make the following changes : Enabled : check Preferred Binding : POST Default URL : http://<DestinationSiteDNSName>:<PORT>/samldest01App Now click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes : Replicated Cache Enabled : Uncheck / Check Contact Person Given Name Contact Person Surname Contact Person Type Contact Person Company Contact Person Telephone Number Contact Person Email Address Organization Name Organization URL Published Site URL : http://<DestinationSiteDNSName>:<PORT>/saml2 Entity ID : ( Destination Domain name) Single Sign-on Signing Key Alias Single Sign-on Signing Key Pass Phrase Confirm Single Sign-on Signing Key Pass Phrase Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say SP_metadata.xml ).  Copy service provider metadata ( SP_metadata.xml ) to Source Domain and identity provider metadata ( idp_metadata.xml ) to the Destination Domain as shown below : -- Now configure Service Provider metadata on SAML Identity Provider in Source Site : Log in to the source site Admin Console and click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapper ”  –> ” SAML2_CredentialMapper ” –> ” Management ” –> ” New ” –> ” New Web Single Sign-On Service Provider Partner ” : "> Name this ”New Web Single Sign-On Service Provider Partner” as “SAML_SSO_SP01″ and select the SP_metadata.xml file. Click on the newly created ” SAML_SSO_SP01 ” and enter the following : Name :  SAML_SSO_SP01 Enabled :  Checked Description  : SAML_SSO_SP01 Key Info Included  : Check "> Click on Site info and verify the data : ------ Now configure Identity Provider metadata on SAML Service Provider in Destination site : Login to Destination Site Admin Console : Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> Authentication -> SAML2_IdentityAsserter –> ” Management ” –> ” New ” –> “ New Web Single Sign-On Identity Provider Partner ” say ” SAML_SSO_IDP01 ” and then select ” idp_metadata.xml ” : Click on ” SAML_SSO_IDP01 ” and enter the following : Name : SAML_SSO_IDP01 Enabled : Check Description : SAML_SSO_IDP01 Redirect URIs : /samldest01App/restricted01/samldest01services.jsp We have successfully configured SAML 2 with Weblogic Server...!! Deploy the source and destination application and check if SAML 2.0 works fine. DOWNLOAD : Source Application. ( NEW ) DOWNLOAD : Destination Application. ( NEW ) Note : - To test this sample application login using " weblogic " user.The principal I have used in weblogic.xml file of this application is : <security-role-assignment> <role-name>SamlTrainee</role-name> <principal-name>Administrators</principal-name> </security-role-assignment> - So you should be able to login to this application with a user " Administrators " or any user who is part of a group called " Administrators ".  - When you access the Source application, you will get a challenge, enter username " weblogic " and its password. Now click on the redirect URL and you should not be asked for a challenge while accessing the Destination app. -  In the application jsp pages I have specified " localhost " in the URL, change it to your respective host / IP address. - If you have the Source and Destination domain on the same machine, then make sure you edit the jsp page and change the redirect URL to IP / host, donot use " localhost " as it may go into a loop.  

Note : - To setup SAML 2 with Weblogic 10.3.x we need to create a security database even before creating domain. - The RDBMS security store is required by the SAML 2.0 security providers in production...

Weblogic Security

Steps to create a .jks keystore using .key and .crt files...

F5 load balancers generate .crt and .key files, which has to be converted to a .jks keystore to configure it with Weblogic Server. Here .crt is the signed certificate from a CA and .key contains the private key. These are in PEM format. Step 1 : Copy the crt contents to a notepad and save this file with .pem extension. Eg : cert.pem Contents : —–BEGIN CERTIFICATE—– MIIFMDCCBBigAwIBAgIDDCucMA0GCSqGSIb3DQEBCwUAMDwxCzAJBgNVBAYTAlVT . . . EMJj7aen/ouZThhszQ7lYbvCsQRQlGkKHR0byY4TBoq7kIG5nb64tXvQoP048G7o Ghf+c+KmfOwUoLoXSzW9CnXgV0EY6MQ5pluL6wB5W6NHQ7Xf —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i . . knYYCnwPLKbK3opie9jzzl9ovY8+wXS7FXI6FoOpC+ZNmZzYV+yoAVHHb1c0XqtK LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw== —–END CERTIFICATE—– —–BEGIN CERTIFICATE—– MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT . . NhGc6Ehmo21/uBPUR/6LWlxz/K7ZGzIZOKuXNBSqltLroxwUCEm2u+WR74M26x1W b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S —–END CERTIFICATE—– Step 2 : Copy the contents of private key and save it into a notepad with .pem extension. Eg : key.pem Contents : —–BEGIN RSA PRIVATE KEY—– MIIEogIBAAKCAQEAqm1GacPeZT/cb0Fn2/cF9tcZZZ/UOalrbSad8Qx7Dg467hee . . US8hanaMxYSDY17u89OxSiJ70PnsArui47pF9GepaUaOgWn/IKM= —–END RSA PRIVATE KEY—– Step 3 : Run the following command : Syntax : $ java utils.ImportPrivateKey keystore storepass storetype keypass alias certfile keyfile keyfilepass  Command : java utils.ImportPrivateKey -keystore identity.jks -storepass password -keyfile mykey -keyfilepass password -certfile certs.pem -keyfile key.pem -alias mykey Sample output : d:\Oracle\Middleware1036\user_projects\domains\wild_card_certificate_domain\certificates>java utils.ImportPrivateKey -keystore identity.jks -storepass password -keyfile mykey -keyfilepass password -certfile cert.pem -keyfile key.pem -alias mykey No password was specified for the key entry Key file password will be used Imported private key key.pem and certificate cert.pem into a new keystore identity.jks of type jks under alias mykey We have now created an identity.jks file. To see the contents of this keystore use the following command : Command : keytool -list -v -keystore identity.jks -storepass password  --- < Additional Information > The ImportPrivateKey utility is used to load a private key into a private keystore file. You can use the CertGen utility to create a .key ( testkey ) and .crt ( testcert ) and then use the ImportPrivateKey utility to create a .jks file. Note: By default, the CertGen utility looks for the CertGenCA.der and CertGenCAKey.der files in the current directory, or in the WL_HOME/server/lib directory, as specified in the weblogic.home system property or the CLASSPATH. Alternatively, you can specify CA files on the command line. If you want to use the default settings, there is no need to specify CA files on the command line. 1. Enter the following command to generate certificate files named testcert with private key files named testkey: Command : $ java utils.CertGen -keyfilepass mykeypass -certfile testcert -keyfile testkey 2. Convert the certificate from DER format to PEM format. Command :  $ java utils.der2pem CertGenCA.der 3. Concatenate the certificate and the Certificate Authority (CA). Command :  $ cat testcert.pem CertGenCA.pem >> newcerts.pem  4. Create a new keystore named mykeystore and load the private key located in the testkey.pem file.  Command :  $ java utils.ImportPrivateKey -keystore mykeystore -storepass mypasswd -keyfile mykey -keyfilepass mykeypass -certfile newcerts.pem -keyfile testkey.pem -alias passalias

F5 load balancers generate .crt and .key files, which has to be converted to a .jks keystore to configure it with Weblogic Server. Here .crt is the signed certificate from a CA and .key contains the...

Steps to create a self-signed certificate and configure Custom Identity and Custom Trust with Weblogic Server using Keytool...

Below are the steps to create a self signed certificate : Command 1 :  keytool -genkey -alias mykey -keyalg RSA -keysize 1024 -validity 365 -keypass privatepassword -keystore identity.jks -storepass password Note : List of keytool commands which are changed in java 1.6 : -export, renamed to -exportcert -genkey, renamed to -genkeypair -import, renamed to -importcert All previous commands are still supported in this release ( keytool in java 1.6 ) and will continue to be supported in future releases. To create a 2048 bit SHA2/SHA256 certificate use the following command :Command :keytool -genkey -alias mykey -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 365 -keypass privatepassword -keystore identity.jks -storepass password Command 2 : keytool  -export -alias mykey -file root.cer -keystore identity.jks -storepass password Command 3 :  keytool -import -alias mykey -file root.cer -keystore trust.jks -storepass password ">  < Additional Info >  To see the contents of the keystore use the following command : Command : keytool -list -v -keystore identity.jks -storepass password To see the contents of an individual certificate ( like root.cer in our case ). Command : keytool -printcert -file root.cer Copy the keystore files in the domain_home location : Below are the steps to configure Custom Identity and Custom Trust with Weblogic Server : Step 1 : Login to Weblogic Admin console --> Environment --> Servers --> < server_name_where_ssl_has_to_be_configured > --> Configuration -> General --> SSL Listen Port Enabled ( Check ) Note : The default SSL Listen Port would be 7002, change it if required.  Step 2 : Click on Keystores tab under " Configuration " tab : Step 2a : Click on the drop down menu next to Keystores and sleect " Custom Identity and Custom Trust "  Step 2b : Now fill in the following information : ---Identity---   Custom Identity Keystore : < location_of_identity_keystore_that_you_have_created> NOTE : By default WLS will look for this keystore file in domain_home location.  Custom Identity Keystore Type : jks  Custom Identity Keystore Passphrase: < This_would_be_your_storepass >  ---Trust---  Custom Trust Keystore : < location_of_trust_keystore_that_you_have_created> NOTE : By default WLS will look for this keystore file in domain_home location.  Custom Trust Keystore Type : jks  Custom Trust Keystore Passphrase: < This_would_be_your_storepass > Step 2c : Now save the changes and click on " SSL " tab : Private Key Alias: < This_would_be_your_certificate_alias > Private Key Passphrase: < This_would_be_your_keypass > Step 3 : Save the changes and click on the " >Advanced " field under the " SSL " tab :   Set the " Hostname Verification: " to None ( from the drop down menu ). Note : We need to select the hostname verification as none if the CN of the certificate is not the same as the hostname of the machine where WLS is installed.   Now access your Weblogic Admin console over https URL :  " https://localhost:7002/console "

Below are the steps to create a self signed certificate : Command 1 :  keytool -genkey -alias mykey -keyalg RSA -keysize 1024 -validity 365 -keypass privatepassword -keystore identity.jks -storepass...

Steps to create a new domain on Weblogic Server 12.1.2.0.0...

Note : - Prior to running the Configuration Wizard to create a domain on a UNIX or Linux operating system, if you have not already done so, set the CONFIG_JVM_ARGS environment variable to the following value:     " -Djava.security.egd=file:/dev/urandom " This decreases the amount of time it takes for the Configuration Wizard to create or update a domain. - Quick Start Configuration Wizard can be used only to configure the various sample domains, such as MedRec and the Examples Server, in your WebLogic Server installation. The Quick Start Configuration Wizard supports only the Derby (JavaDB) database driver. If you are using another database, you cannot use the Quick Start Configuration Wizard to create your domain.  - You can start Quick Start Configuration Wizard in two ways : 1. Select the Automatically Launch Quick Start Configuration Wizard option on the Installation Complete screen of the WebLogic Server installer. 2. Run the config.cmd / config.sh script located in ORACLE_HOME/oracle_common/common/bin as follows : " config.cmd -target=config-oneclick " in windows and " config.sh -target=config-oneclick " in Linux. - Prior to manually running the Configuration Wizard in Quick Start mode, you must set the CONFIG_JVM_ARGS environment variable to specify the full path and JAR file name for each template that you want to use for the domain. To set CONFIG_JVM_ARGS on a Windows system: set CONFIG_JVM_ARGS="-DuserTemplates=C:/Oracle/Middleware/wlserver/common/templates/wls/wls.jar,C:/Oracle/Middleware/wlserver/common/templates/wls/wls_webservice_jaxws.jar" To set CONFIG_JVM_ARGS on a UNIX: export CONFIG_JVM_ARGS="-DuserTemplates=/Oracle/Middleware/wlserver/common/templates/wls/wls.jar,/Oracle/Middleware/wlserver/common/templates/wls/wls_webservice_jaxws.jar" Steps to create a new WLS 12.1.2.0.0 domain : Step 1 : - After installing Weblogic server, you can check/select " Automatically Launch the Configuration Wizard " and finish the installation. This would automatically start the configuration Wizard.  - You can also start the Configuration Wizard using config script located at : On Windows: <MWHOME>\oracle_common\common\bin\config.cmd  ( OR " choose Start > All Programs > Oracle > Oracle Home > WebLogic Server version > Tools > Configuration Wizard. " ) On UNIX: <MWHOME>/oracle_common/common/bin/config.sh Note : - If you have a WLS zip installer then you need to use the configure.sh script to create a basic domain instead of the config.sh script. Even though the config.sh script is present it will not work. - When you run the config.cmd or config.sh command, the following error message might be displayed to indicate that the default cache directory is not valid: *sys-package-mgr*: can't create package cache dir You can change the cache directory by including the -Dpython.cachedir=valid_directory option in the command line. To create a log file of the Configuration Wizard session, include the -log=config.log -log_priority=debug parameter in the command. You can specify any file name for the log file, such as config_today.log. The log file is stored in the logs directory of the Oracle Middleware home directory. - If you cannot use GUI mode then Oracle recommends to use WLST to create a new or extended domain.  Step 2 : Step 3 : - There are three template categories that you can choose from : * All Templates ( Default ) * Oracle * Oracle weblogic Server and Coherence  Step 4 : Step 5 : Step 6 : - You now have an option to configure nodemanager in the configuration wizard. - Nodemanager can be configured at the domain level or machine level. - By default nodemanager would be configured at the domain level. Step 7 : Step 8 : Step 9 :

Note : - Prior to running the Configuration Wizard to create a domain on a UNIX or Linux operating system, if you have not already done so, set the CONFIG_JVM_ARGS environment variable to the following...

Steps to install Oracle Weblogic Server 12.1.2.0.0...

We can install WLS 12.1.2.0.0 in two modes : - GUI mode - Silent mode Note : - We donot have the console mode option anymore - JDK is not bundled along with the installer, so install JDK first and then install Weblogic Server. - If this is the first time you are installing Weblogic Server on your machine then an Oracle Inventory is created first and then WLS is installed. If Oracle Inventory is already present then the new installation details would be appended to this file. - Oracle Inventory is similar to the registry.xml file that used to get created in older WLS versions. Oracle Central Inventory keeps track of all the Oracle Software products installed on all the Oracle homes on your system, provided the products were installed using Oralce Universal Installer. Below are the steps to install Oracle Weblogic Server 12.1.2.0.0 on a Linux machine : Step 1 : - Install JDK 1.7 - Download the WLS installer " wls_121200.jar ". - Run the following command : Command :  java -jar wls_121200.jar Note : Make sure you run the above command in an X-Windows terminal.  -   Step 2 : Enter the path for Oracle_Home Step 3 : There are three types of Installations : 1. Weblogic Server Installation - For WebLogic Server and Coherence standard installation topology - no server examples 2. Coherence Installation - to deploy and manage Coherence applications using the WebLogic Management Framework. - no server examples 3. Complete Installation - WLS + Coherence + server examples. In this example I have selected the default option i.e Weblogic Server Installation.  Step 4 :  Step 5 :   Step 6 : Note : In this step you can create a response file, which can be used later to install weblogic in Silent Mode. Step 7 : Step 8 : Note : If you check the option " Automatically Launch the Configuration Wizard " and finish the installation, then you will begin configuring a new domain.

We can install WLS 12.1.2.0.0 in two modes : - GUI mode - Silent mode Note : - We donot have the console mode option anymore - JDK is not bundled along with the installer, so install JDK first and then...

Weblogic Security

Steps to configure SAML 2.0 with Weblogic Server (using embedded LDAP as a security store - Only for Dev Environment)...

NOTE : - A WebLogic Server instance that is configured for SAML 2.0 SSO cannot sent a request to a server instance configured for SAML 1.1, and vice-versa.  - WebLogic Server does not support encrypted assertions in SAML.  - It is always recommended to create a domain in which the RDBMS security store is configured.  - The RDBMS security store is required by the SAML 2.0 security providers in production environments so that the data they manage can be synchronized across all the WebLogic Server instances that share that data.  - Note that Oracle does not recommend upgrading an existing domain in place to use the RDBMS security store. If you want to use the RDBMS security store, you should configure the RDBMS security store at the time of domain creation. If you have an existing domain with which you want to use the RDBMS security store, create the new domain and migrate your existing security realm to it.  - If you are configuring SAML 2.0 services in a cluster, each Managed Server in that cluster must be configured individually.  - You cannot configure SAML 2.0 general services in a WebLogic Server instance until you have first configured either the SAML 2.0 Identity Assertion or SAML 2.0 Credential Mapping provider and restarted the server instance. - Note that I have not used an RDBMS security store in the following configuration, ( I am using embedded LDAP ) This is only for demonstration purpose and is not recommended for production environments. - While configuring SAML2 with Weblogic Server in production environment, please make sure you create a domain with RDBMS security store configured. Prerequisite : - In the following example I have created two domains " SAML2_IDP_Source_Domain " and " SAML2_SP_Destination_Domain " on Weblogic Server 12.1.1. - I have created self signed certificates and configured SSL on both the domains. - Source domain HTTP and HTTPS ports are 7001 and 7002 respectively. - Destination domain HTTP and HTTPS ports are 7003 and 7004 respectively. SAML Souce site configuration : - Create a " Credential Mapper " on Weblogic Source domain, i.e on the IDP end. - Login to Source domain - Weblogic console --> Click on ” myrealm ” –> ” Providers ” –> ” Credential Mapping ” –> and add a ” SAML2CredentialMapper ” say ” SAML2_CredentialMapper ” as shown below : - Now click on the newly created SAML2CredentialMapper say ” SAML2_CredentialMapper ” and make the following changes : Issuer URI : http://www.souresite.com/saml Name Qualifier : sourcesite.com "> - Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Identity Provider ” and make the following changes : Enabled : check Preferred Binding : POST - Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes : Replicated Cache Enabled – Uncheck / Check Contact Person Given Name Contact Person Surname Contact Person Type Contact Person Company Contact Person Telephone Number Contact Person Email Address Organization Name Organization URL Published Site URL : http://<SourceSiteDNSName>:<PORT>/saml2 Entity ID : ( Source Domain name) Single Sign-on Signing Key Alias Single Sign-on Signing Key Pass Phrase Confirm Single Sign-on Signing Key Pass Phrase Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say idp_metadata.xml ). We need to copy this file to the destination domain later. Destination Site Configuration :  - Create an Identity Asserter on the destination domain, i.e SP end. - Login to Destination domain - Weblogic console --> Click on ” myrealm ” –> ” Providers ” –> ” Authentication ” –> new ” SAML2IdentityAsserter “ say ” SAML2_IdentityAsserter : Click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 Service Provider ” and make the following changes : Enabled : check Preferred Binding : POST Default URL : http://<DestinationSiteDNSName>:<PORT>/samldest01App Now click on ” Servers ” –> Admin Server –> ” Federation Services ” –> ” SAML 2.0 General ” and make the following changes : Replicated Cache Enabled : Uncheck / Check Contact Person Given Name Contact Person Surname Contact Person Type Contact Person Company Contact Person Telephone Number Contact Person Email Address Organization Name Organization URL Published Site URL : http://<DestinationSiteDNSName>:<PORT>/saml2 Entity ID : ( Destination Domain name) Single Sign-on Signing Key Alias Single Sign-on Signing Key Pass Phrase Confirm Single Sign-on Signing Key Pass Phrase Save the changes and export the IDP metadata into a XML file –> Click on “ Publish Meta Data ” button. ( say SP_metadata.xml ).  Copy service provider metadata ( SP_metadata.xml ) to Source Domain and identity provider metadata ( idp_metadata.xml ) to the Destination Domain as shown below : -- Now configure Service Provider metadata on SAML Identity Provider in Source Site : Log in to the source site Admin Console and click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> ” Credential Mapper ”  –> ” SAML2_CredentialMapper ” –> ” Management ” –> ” New ” –> ” New Web Single Sign-On Service Provider Partner ” : "> Name this ”New Web Single Sign-On Service Provider Partner” as “SAML_SSO_SP01″ and select the SP_metadata.xml file. Click on the newly created ” SAML_SSO_SP01 ” and enter the following : Name :  SAML_SSO_SP01 Enabled :  Checked Description  : SAML_SSO_SP01 Key Info Included  : Check "> Click on Site info and verify the data : ------ Now configure Identity Provider metadata on SAML Service Provider in Destination site : Login to Destination Site Admin Console : Click on ” Security Realms ” –> ” myrealm ” –> ” Providers ” –> Authentication -> SAML2_IdentityAsserter –> ” Management ” –> ” New ” –> “ New Web Single Sign-On Identity Provider Partner ” say ” SAML_SSO_IDP01 ” and then select ” idp_metadata.xml ” : Click on ” SAML_SSO_IDP01 ” and enter the following : Name : SAML_SSO_IDP01 Enabled : Check Description : SAML_SSO_IDP01 Redirect URIs : /samldest01App/restricted01/samldest01services.jsp We have successfully configured SAML 2 with Weblogic Server...!! Deploy the source and destination application and check if SAML 2.0 works fine. DOWNLOAD : Source Application. ( NEW ) DOWNLOAD : Destination Application. ( NEW ) Note :- To test this sample application login using " weblogic " user.The principal I have used in weblogic.xml file of this application is : <security-role-assignment> <role-name>SamlTrainee</role-name> <principal-name>Administrators</principal-name> </security-role-assignment> - So you should be able to login to this application with a user " Administrators " or any user who is part of a group called " Administrators ". - When you access the Source application, you will get a challenge, enter username " weblogic " and its password. Now click on the redirect URL and you should not be asked for a challenge while accessing the Destination app.-  In the application jsp pages I have specified " localhost " in the URL, change it to your respective host / IP address.- If you have the Source and Destination domain on the same machine, then make sure you edit the jsp page and change the redirect URL to IP / host, donot use " localhost " as it may go into a loop.  

NOTE : - A WebLogic Server instance that is configured for SAML 2.0 SSO cannot sent a request to a server instance configured for SAML 1.1, and vice-versa.  - WebLogic Server does not support encrypted...

Weblogic Security

Steps to configure Kerberos / SPNEGO / NTLM authentication with Weblogic Server running on Oracle JDK :

* The AD machine used in this configuration is :  SLKRBTRN6-01.slkrbtrn6.bea.com ( Windows 2008 R2 ) * Weblogic Server is on machine : SLKRBTRN6-03. ( Windows XP ) ------- Step 1 : - Create a new user say, " wlsclient " on AD for your Weblogic server instance.         Note : - The account type should be "User", not a "Computer" in the AD. - Check password never expires option for the user.  - DES encryption type is disabled by default on Windows 2008 AD and hence donot check this option for the user. - If your AD is on Windows 2003, enable DES encyption type for your user --> after enabling this option make sure you reset the password for this user. - If you want to use AES encryption type make sure you check " This account supports AES 128 bit encryption "/ "This account supports AES 256 bit encryption " in the username --> properties --> Account Options field. - If you want to use  AES256-SHA1 cipher strength then, You need to download and install this bundle which provides "unlimited strength" policy files which contain no restrictions on cryptographic strengths. * For Oracle JDK 6: Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 from  Link : http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html. * For Oracle JDK 7: Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 from Link : http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html .  Overwrite 2 jar files under “<JAVA_HOME>/jre/lib/security” directory with 2 jar files inside downloaded zip file. Step 2 : Create a krb5.ini file. Syntax :  ***** [libdefaults] default_realm = <Identifies the default realm. Set its value to your Kerberos realm - all caps> default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes =  aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 ticket_lifetime = 600 kdc_timesync = 1 ccache_type = 4  [realms] <Your Kerberos realm – remember all caps> = { kdc = <IP address of the KDC/AD server> (For Unix systems, you need to specify port 88, as in <IP-address>:88) admin_server = <FQDN - host name of the KDC/AD server> default_domain = <Windows domain name in caps> } [domain_realm] .<DNS domain name suffix, starting with .> = <Your Kerberos realm – remember all caps> <DNS domain name suffix.> = <Your Kerberos realm – remember all caps>  [appdefaults] autologin = true forward = true forwardable = true encrypt = true  *****      Note : * This file has to be created on the machine where Weblogic Server is installed.  * If you have Weblogic Server installed on a Windows machines, create a file named krb5.ini  / On Unix machines, the file is called krb5.conf instead of krb5.ini.  * See the following default Kerberos configuration files and their locations: [Windows] The default location is c:\winnt\krb5.ini. Note: if the krb5.ini file is not located in the c:\winnt directory it might be located in c:\windows. [Linux] The default location is /etc/krb5.conf. [AIX] [HP-UX] [Solaris] On other Unix platforms, the default location is /etc/krb5/krb5.conf.       Step 3 : To check if the krb5.ini file you created is correct, run the following command : Command : kinit wlsclient OR kinit wlsclient@<REALM>     Step 4 : ( Run the following commands on AD machine ). Let's make sure that there are no duplicate SPNs in your AD box and then add an SPN to "wlsclient" user : Syntax : setspn -S HTTP/<wls-server-name>@<REALM-NAME> <account_name>  Command :  setspn -S HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM wlsclient  NOTE : The above command is optional. But it is always good to check for duplicate SPNs before creating a keytab file. Now create a keytab file : Syntax : ktpass –princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> –pass password -crypto all -kvno 0 -ptype KRB5_NT_PRINCIPAL –out <keytab-file-name> Command :  ktpass -princ HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM -mapuser wlsclient -pass Weblogic1 -crypto all -kvno 0 -ptype KRB5_NT_PRINCIPAL -out wlsclient.keytab .               Note : * When you run the ktpass command it adds the SPN to the user account and also create a keytab file. However we are running the setspn -S command to make sure there are no duplicate SPNs in AD.   * Running ktpass will modify the account details, changing the user login name to match the service principal name – note that this is a consequence of running the above command, not something you need to do manually * Click on the user " wlsclient " properties to see the change. * Now copy the keytab file generated to machine where Weblogic Server is installed.  * If you are using Windows 2003 AD then use the following command : ktpass –princ HTTP/<wls-server-name>@<REALM-NAME> -mapuser <account-name> –pass password -crypto DES-CBC-CRC -ptype KRB5_NT_PRINCIPAL –out <keytab-file-name>     Step 5 : After copying the keytab file to the machine where Weblogic Server is installed, run the klist command to see the contents of the keytab file. Syntax : klist -k <keytab> Command : klist -e -k wlsclient.keytab     If your principal was created properly, you should be able to request a TGT (ticket Granting Ticket) from Kerberos using that principal. If the keytab file was generated properly, then you should be able to use this file instead of the password of your account. kinit tests both simultaneously.  Syntax :  kinit –k –t <keytab-file> <account-name> Command : kinit -J-Dsun.security.krb5.debug=true -k -t wlsclient.keytab HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM OR  java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit -k -t wlsclient.keytab HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM   . Note : * In UNIX use the -V switch or else there wont be any output. (  kinit -V –k –t <keytab-file> <account-name> ) *  The above debugs will not work in UNIX. It is specific to Windows. *  When you lock and unlock your computer, you are causing Windows to request new Kerberos tickets. Another way to force Windows to request new Kerberos tickets is to run " klist purge " from the command prompt.  This explicitly asks Windows to dump your currently Kerberos tickets and thus, request new ones.       Step 6 : Now, lets configure Weblogic Server. Create a file called " krb5Login.conf " and place it in the Weblogic Server domain directory : Syntax : com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="<Service principal account>@<Kerberos realm>" useKeyTab=true keyTab=<keytab> storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required principal="<Service principal account>@<Kerberos realm>" useKeyTab=true keyTab= <keytab> storeKey=true debug=true; };     krb5Login.conf : com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required  principal="HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM"  useKeyTab=true keyTab=wlsclient.keytab storeKey=true debug=true; }; com.sun.security.jgss.krb5.accept { com.sun.security.auth.module.Krb5LoginModule required  principal="HTTP/SLKRBTRN6-03@SLKRBTRN6.BEA.COM"  useKeyTab=true keyTab=wlsclient.keytab  storeKey=true debug=true; };     Note : * If you are using JDK 1.5 then change the following line in the above file from " com.sun.security.jgss.krb5.accept " to " com.sun.security.jgss.accept ". i.e donot use krb5 in the accept and initiate method in the above file if you are using JDK 1.5. * Weblogic Server domain directory is the default location of keytab file and krb5Login.conf file. * Even an extra space in krb5Login.conf will cause errors while parsing the file. Below is a sample file, copy this file to your machine and only change the <UPN> ( "<Service principal account>@<Kerberos realm>" ) and <keytab> entries in it. DONOT give any extra spaces ..!! Krb5Login.conf - Right click here and select " Save link as... " to save this file..!!   Step 7 :  Now lets add few -D parameters to Weblogic Server startup script.  -Djava.security.auth.login.config=krb5Login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -Djava.security.debug=configfile,configparser,gssloginconfig   // This is the debug flag to check if the config files get parsed properly. -Dsun.security.krb5.debug=true  < Additional -D parameters that can be set > -Djava.security.krb5.realm=<realm> -Djava.security.krb5.kdc=<kdc>  -Dweblogic.security.krb5.useGSSName=true  // Use this flag if you are configuring Kerberos with multiple AD domains, you also need to apply patch for Bug 14069872 ( fixed in 12.1.1 ) for this flag to work. --  In windows edit " startWebLogic.cmd " file and add the following java options : set JAVA_OPTIONS=%JAVA_OPTIONS% -Djava.security.auth.login.config=krb5Login.conf –Djavax.security.auth.useSubjectCredsOnly=false –Dweblogic.security.enableNegotiate=true -Dsun.security.krb5.debug=true In UNIX edit " startWebLogic.sh " file and add the following java options : JAVA_OPTIONS=”${JAVA_OPTIONS} -Djava.security.auth.login.config=krb5Login.conf –Djavax.security.auth.useSubjectCredsOnly=false –Dweblogic.security.enableNegotiate=true -Dsun.security.krb5.debug=true”           Step 8 : Login to weblogic console and configure Active Directory provider. Change the control flags of all the providers to " Optional ". If you have set control flag as sufficient then reorder the providers and make sure Active Directory providers is the first provider in the list.       . Step 9 : Now, create a " NegotiateIdentityAsserter " as shown below :           So now, the security provider configuration should look like :     .     Step 10 : Setup your browser for Kerberos Authentication. * No special configuration needed for Chrome Browser. * For Mozilla Firefox browser : 1. Start Firefox. 2. Enter about:config in the Location Bar. 3. Enter the filter string network.negotiate. 4. Double click on network.negotitate-auth.delegation-uris  and enter " http://,https:// " 5. Double click on network.negotitate-auth.trusted-uris and enter " http://,https:// "  * For Internet Explorer : Configure Local Intranet Domains    1. In Internet Explorer, select Tools > Internet Options.    2. Select the Security tab.    3. Select Local intranet and click Sites.    4. In the Local intranet popup, ensure that the Include all sites that bypass the proxy server and Include all local (intranet) sites not listed in other zones options are checked.    5. Click Advanced.    6. In the Local intranet (Advanced) dialog box, add all relative domain names that will be used for Oracle WebLogic Server instances participating in the SSO configuration (for example, myhost.example.com) and click OK. Configure Intranet Authentication    1. Select Tools > Internet Options.    2. Select the Security tab.    3. Select Local intranet and click Custom Level... .    4. In the Security Settings dialog box, scroll to the User Authentication section.    5. Select Automatic logon only in Intranet zone. This option prevents users from having to re-enter logon credentials, which is a key piece to this solution.    6. Click OK. Verify Proxy Settings If you have a proxy server enabled:    1. Select Tools > Internet Options.    2. Select the Connections tab and click LAN Settings.    3. Verify that the proxy server address and port number are correct.    4. Click Advanced.    5. In the Proxy Settings dialog box, ensure that all desired domain names are entered in the Exceptions field.    6. Click OK to close the Proxy Settings dialog box. Now, when you access your Weblogic Admin Console, you should be able to login to it without entering a username / password.     You can use the following Kerberos DEBUG App for troubleshooting : Downlaod Kerberos DEBUG App

* The AD machine used in this configuration is :  SLKRBTRN6-01.slkrbtrn6.bea.com ( Windows 2008 R2 ) * Weblogic Server is on machine : SLKRBTRN6-03. ( Windows XP ) ------- Step 1 : - Create a new user...