Recently I made a dumb mistake. I was trying to enable single sign on (SSO) and hastily set everything up and restarted all services. However, once SSO was enabled I realized that I had not prior to enabling set my SSO user account with admin access in Hyperion. Since SSO was enabled, the admin user was no longer available to use for login because the SSO user is now enforced. With SSO enabled, the 'admin' user becomes obsolete.
In the past versions like 11.1.2.2 this was no big deal as you could always login with your username and password using /interop to login directly to Shared Services. However, in 11.1.2.4 you have to go through Workspace to get to Shared Services, enforcing the SSO login. Without admin privileges on your user account you cannot disable SSO, or make any setting changes at all! I had essentially locked myself and everyone else out of the system.
To restore the system I remembered a setting in Workspace, "Allow Direct Login After SSO Failure". This is a good fallback setting if SSO fails, giving you a way to access Hyperion using the old username/password combo. This would have been ideal to set BEFORE I locked myself out... At this point I can't make any changes to the system due to lack of administrator privileges.
From the help pages in Workspace:
However, I recall that using epmsys_registry we can make changes to the EPM system registry without any credentials. Perhaps it's possible to change this setting. Looking in the epm registry report, it looks as if the field is available in WORKSPACE_LWA.
Using the object id, you can view and change the setting...
/export/u1/app/Oracle/Middleware/user_projects/epmsystem1/bin/epmsys_registry.sh view \#18349408fd0bc34c317d176d1562f332264S7f57
/export/u1/app/Oracle/Middleware/user_projects/epmsystem1/bin/epmsys_registry.sh updateproperty \#18349408fd0bc34c317d176d1562f332264S7f57/@AllowDirectLogonAfterSSO true
(note the object id differs between the screenshot and commands because I took the screenshot from a different system. They should be the same in practice.)
Once I restarted the system this property was in place. However, the ability to login using the username/password combo only appears if SSO fails. There was nothing inherently wrong with SSO, it was working just fine. I had to make SSO fail in order to login. This seemed pretty easy, I just accessed Workspace directly rather than going through the SSO enabled web server. Consequently, the SSO token was not passed and the login prompt appeared. Finally... I was able to login as admin and provision my user id with admin privileges to gain access!
One might argue that the option to allow direct login if SSO fails should always be set. In my opinion, it is way too easy for malicious users to trick the SSO into failing and then gain access to the direct login prompt. This seems to be a security risk. I think using the method presented above,makes it possible to turn it on and off on demand if you need to get a backdoor into the system without it being enabled all the time.
