Ace

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...