After deleting users they are not removed from portal30.wwsec_person

Question

I am building a customized script to carry on users self registration.
the script is going great and user is created and i can log into portal
successfully with this new created user.
I relogin as portal administrator and delete this new user and now if i tried
to list portal users I cant see the user.
But when I try to rerun my script to recreate this user again it fails when I
investigated I found that it fails because the entry of this user is removed
from portal30_sso.wwsec_person while it still exists in portal30.wwsec_person
so the script fails as there is duplicate in primary key.
Is this a bug in portal 309 that when the user is deleted it is not removed
from portal30.wwsec_person

Answer 1

This is actually a combination of intended behavior/design and a bug.
Let me first explain why there is a user in both the PORTAL30_SSO schema as well as the PORTAL30 schema.
The definition of the user, that can log in, and defines the single sign-on account, is the user's entry in the
WWSEC_PERSON$ table in the PORTAL30_SSO schema. The SSO server actually just uses a subset of the
columns in this table -- those defined in the WWSSO_SSO_USER view.
The same table exists in the PORTAL30 schema, because there is a lot of common infrastructure code
shared by both applications (Login Server, and Portal). The Security and Session Management code
is common, and this code includes the dependency on the WWSEC_PERSON$ table.
Now, assuming that the code was independent (for the sake of argument), why do we still have an entry
for the user in both schemas? As I mentioned earlier, the user entry in the SSO schema is the "master".
The SSO server can have multiple partner applications connected to it. Indeed, on my.oracle.com, the
login server there has at least 4 portals hooked up to it, and a few other non-Portal partner applications,
such as Oracle Mobile.
Each partner application may have a local user profile that it uses to store application specific attributes
of the user. This is stuff that the Login Server is not interested in, and could in no way predetermine for
all conceivable partner applications. So, it is not unreasonable for each partner application to also have
a user record which stores additional attributes of the user (not related to user authentication), and which
can be used to reference other user-related data. For example in the Portal, all the user's privileges
and group memberships are tied to the Portal's user record (foreign key constraints). So, the Portal
being just one partner application of the Login Server, it adhere's to this model and has a user entry
in it's schema corresponding to the user entry in the Login Server.
When a user logs on and accesses a partner application for the first time, the partner application (read Portal)
is expected to automatically create a local profile entry for the user on demand. The Portal does this.
In 3.0.9 and previous versions, to delete a user, you need to delete the user in the Login Server AND the Portal.
The only way to do this is to first delete the user in the Login Server, using the User Portlet.
Then type the user's name into the Portal User Profile portlet (they won't be in the LOV anymore since
you just deleted them from the login server), and click Edit, then Reset To Defaults (this means delete).
You will then get a User Not Found error, since the page is trying to go back to show the details about this user.
(All this has been fixed in 9.0.2 v2, by the way).