Strange Brew

TL;DR:  If you can't ssh using a public key, it could be a SELinux thing. Logging in to a server with ssh using your public key is pretty handy.  While setting up an OEL 6 VM  I ran into a strange error where sshd would not let me log in with a public key, even though my key was in ~oracle/.ssh/authorized_keys.  Password logins worked just fine. Somewhat puzzling: I could ssh into the root account using my public key and without a password. Nine times out of ten, this is a permission problem. Sshd is picky about the permissions on your home directory, ~/.ssh, and the authorized_keys file.  I carefully checked this over - but in this instance permissions were not the problem. The standard advice to debug SSH problems is to run sshd in the foreground with debugging turned on: service sshd stop /usr/sbin/sshd -dD And of course my problem promptly disappeared. Hmmm, so it works in debug mode, but not when running as a daemon. It also works fine...

A customer asked me how they could test their OIF IdP configuration without standing up another relying party. Since OIF can act in both roles (IdP and SP), in turns out you can configure OIF to federate against itself.  It's seems somewhat crazy, and its not all that intuitive, so I thought I would include a few notes on how to set this up. The key is that you must export OIFs SP and IdP metadata and re-import it back into OIF as configured federations. The "/fed/user/testspsso" test page can be then be used to initiate the federation. Here are the basics of how to accomplish this. Step 1: Export your SP and IdP metadata. This is done from the em console. Administration -> Security and Trus t: Step 2) Import the exported meta data back into OIF: Administration->Federations  Click on the "Choose File" button and select the meta-data files you exported in step 1 You should now have an IdP and SP configured under your federation...