OIM: Extending Security Outside of the Enterprise

Question

o.k., long story short, we have an installation of OIM 10.1.4 governing our enterprise security. we have many custom Java J2EE applications registered as Partner Applications on the domain, some using the SSO SDK, and others using MOD_OSSO. everything is working just fine within the enterprise, on our primary security domain. so, pretending our domain is "secure.com", we have "https://app1.secure.com", "https://anotherapp.secure.com", etc., and everyone is playing nicely together.
however, as our company grows and expands, we are starting to get requests from external organizations to integrate via SSO with our security enterprise. again, they are outside of our enterprise, with completely different servers and applications, and would not / could not be on our "secure.com" domain. i don't know all the details, but their applications have their own internal user base, security, etc...
now, i do understand there would be issues around synchronizing user stores, etc., but putting that aside for a minute... is there any way to "extend the reach" of our enterprise security (using Oracle technologies or other...), such that once someone has presented valid credentials on our "secure.com" server, i could return them to "othercompany.com" as a valid user...?
obviously, i can think of Java code i could write that passes an encrypted value around, like Oracle does, but writing my own security code doesn't necessarily sound like a promising option, especially when experts have already written software like this.
so, given a primary user store at our location, and federated user stores elsewhere on other domains, how might i extend our enterprise security and SSO infrastructure safely outside our network?
thanks,
.rich

Answer 1

Hi rhoward,
In most cases, I would say, from a practical standpoint, the answer to your question is "yes".
I suppose that it might be possible to cobble together your own federation endpoint :)...
The thing is that OASIS specifies a number of different "profiles" (=~usage scenarios), and some of them can get pretty complicated, with re-directs going all over the place.
The benefit of using a commercial federation "product" would be that assuming you picked the right one, it would provide the pieces for all of the profiles that you need to support (I don't know which ones, because that will depend on what you need).
It's been awhile since I've worked directly in the federation space, but there were basically 3 "players" awhile ago, Oracle (OIF), RSA (FIM) and Ping Identity. Sun had a federation product as part of their "FAM" product line, but I don't know what the status of that is now.
So, it all depends on what you need. FYI, among the OASIS profiles, the XASP is probably the least complicated, basically just a request-response, but integrating that into a WAM can be a challenge.
Jim