IMPORTANT NOTE :: THE TIME HAS FINALLY ARRIVED. WITH THE RECENT UPDATES TO 11.5.10 (RUP7 AND POSSIBLY ONE PATCH RELEASE BEFORE THAT), THE PROPOSED METHOD HERE NO LONGER WORKS. IT WAS EXPECTED TO COME AT SOME POINT IF FOR CERTAIN WITH R12 WHERE MOD_PLSQL IS RETIRED FROM THE EBS ENVIRONMENT ENTIRELY. SO FOR A POINT OF HISTORY AND INTEREST, I WILL LEAVE THIS UP, BUT AGAIN IT WILL CEASE TO WORK PRIOR TO ARRIVING AT R12. I HAD HOPED FOR DIFFERENT, BUT THATS OKAY.

If you are looking for a way to build your own Single Sign On to Oracle Self Service Environment, here is an idea that you might like to try (Note : This solution requires 10g RUP patch instance or greater) :

Note: There is a remote chance that the authentication method used here will not function properly under an R12 environment. My guess right now is that R12 will leverage some form of LDAP. However, this is not to be considered a detractor. Reason I say that is because I think that the redirect logic will continue to be valid... only the authentication process would be non-applicable. So, I am suspecting that under R12, I will only need to comment out the authentication logic and leave the redirect logic in place... since under LDAP environments, I would already be pre-authenticated when entering the direct connect logic discussed here. Of course I will have to wait till sometime next year (2008) to find that out, which is when we will start looking at what impact R12 will have to our environment.

I am presuming that if you are reading this, you have some working knowledge of Oracle Applications and how you log into the application. Given that, most everyone knows that we can post the following values to the https://your domain/OA_HTML/fndvald.jsp :

username this is the username your wanting to login with
password this is the password your wanting to login with
rmode this will always be 2
home_url this is the url you wish to be returned to when exiting

Now you might ask yourself, where do I get my password from... you will need to take the responsibility of people maintaining their password on their own, and generate it for them via provided APIs. We store keys which when run against an algorithm match a password associated to that individuals user account. You could build your own encryption algorithm, or you could use Oracle's DBMS_OBSUFUCATION package. However, I won't digress into that any more than what I have said already.

Pages: 1· 2