Ace

 These tips will help you get that extra data to help with self-troubleshooting: WebLogic Installer in debug mode: There are times when a webLogic installer fails in the middle and you do not have a clue what is going wrong (except for a single fat error message). Consider starting the installer with extra bit of logging enabled. Here is the syntax and applicable logging level flags (holds true for 11g as well):       <installer_name> [-mode={console|gui|silent}] [-silent_xml=<file_name>] [-log=<file_name>] [-log_priority={debug|info|warn|error|fatal}]        e.g., wls1032.exe -mode=console -log install.log -log_priority=debug Applying patch with debug logging level: Enable debug logging when applying the patch to get more insight into what is happening:        bsu.sh [-log=<file_name>] [-log_priority={trace|debug|info|warn|error|fatal}] Checking the Debu...

In an IdP-initiated use case, the identity provider is configured with specialized links that refer to the desired service providers. These links actually refer to the local IdP's Single Sign-On Service and pass parameters to the service identifying the remote SP. So instead of visiting the SP directly, the user accesses the IdP site and clicks on one of the links to gain access to the remote SP. This triggers the creation of a SAML assertion that will be transported to the service provider. Here, I discuss the scenario when: WebLogic is IdP WebLogic is SP Suppose we have two domains (SrcDom1 and DstDom1) such that: SrcDom1 - (IdP) - host:27001 - metadata file is idp.xml DstDom1 - (SP) - host:37001 - metadata file is sp.xml - service application deployed as "appB.war" with one of the protected urls as: http://host:37001/appB/admin/services.jsp - Default URL (defined from admin console at "SERVER_NAME/Configuration/Federation Services/SAML 2.0 Serv...

Make sure that we have: Server certificate (which will correspond to identity of our OHS server). This certificate should be contained in "new" custom oracle wallet file named as "ewallet.p12". This certificate can be self-signed/3rd party signed (details of creating such a wallet are out of scope of this document). I will call this wallet as "OHS identity wallet" and the server certificate within it as OHS identity certificate from this point onwards. Root certificate of CA(Certifying authority) who signed OHS identity certificate. Say this is in file "CA_of_ohs.cer". Root certificate of CA who signed weblogic certificate. If you have used 3rd party signed certificate on weblogic, then this will be ROOT certificate of the corresponding CA. If you have used self-signed certificates on weblogic, then our "CA certificate" will be public certificate corresponding to self-signed keypair. We can get this by exporting it from...

Goal : Goal of this document is to help disabling the non-ssl port of EMGC_OMS1 in 11g Grid Control environment such that communication to this server is limited to secure port only come what may. Sounds easy!!! Nope, it is not. Agents (for uploading the data) and browsers (for accessing EM console) used to connect  to this server via front-end OHS server. This OHS server used to talk to our EMGC_OMS1 server over non-secure port (confirm this for you in mod_wl_weblogic.conf ). By disabling non-secure port, we have effectively disabled this access. This document assumes that WebLogic is already running using self-signed certificates. OHS layer is secured (using 3 rd part/self-signed/default certificates) If OHS is secured with default certificates, and you want to secure OHS with self signed and disable OMS non-secure port  side-by-side, please wait for my next post. How : These are the colors your brain will intercept while reading this article: This background color i...

Pushing custom attributes in Custom AttributeStatement (part of SAML assertion, see OASIS SAML2 specification for details), from WebLogic based Identity Provider (IdP) towards a Service Provider (SP) isis not possible in weblogic 10.3.3-). This effectively means that we will not be able to transfer additional user information (for instance email address or some token number) in the form of custom SAML2 attributes in SAML assertion. Here I describe a workaround where-in we will be able to pass data (that ideally should be in the form of AttributeStatement that goes in the SAML assertion generated at IdP end) from WebLogic IdP towards any SP in IdP initiated SSO. If we want to send across any information from IdP end to SP end, what we can do is embed that information into the form which is used to hit the initiator servlet. This information should be available through hidden field. Take following JSP page into consideration (in consistent with discussion at Configuring WebLo...