Hey guys,
I'm trying to figure out how to integrate our application partially using the custom tab functionality. We're hoping to place forms and actions that ought only to be available to authenticated users of both our app and Bullhorn, but the parameters we receive on the iFrame don't provide any security boost particularly. For example, a custom tab for the Candidate entity will yield the following params on the GET request for our iFrame:-
EntityType: Candidate
UserID: x
CorporationID: y
PrivateLabelID: z
EntityID: n
I can't see any (seamless) way of using this that prevents someone from just loading the same URI Bullhorn generates (easily found in the source code) and requesting this directly. Is there further authentication / trust I can leverage here? The only option I can see here is asking the user to log in to Bullhorn (OAuth stylee) via the iFrame even though they're already logged in.
Any tips appreciated!
Custom Tab / Components - Inherently awkward / insecure? - 03161332
Moderators: StaffingSupport, s.emmons, BullhornSupport
Re: Custom Tab / Components - Inherently awkward / insecure? - 03161332
Bumping this issue back -- we're facing the same issues.
We want to make our iframe endpoint secure without forcing the user to login again to our system (or even the Bullhorn system). Anyone with a copy of the GET request string (MITM, sniffing, logs, etc) can try to replay it / edit it without us being able to determine if the request is good or not. I guess we *could* force non-sequential id numbers to prevent guessing of id's, but that does not stop random replays. We'd like something we can use for authentication.
Perhaps if we could store a public key on Bullhorn, along with a nonce timestamp or auto-incrementing message number, and have it generate security keys for each iframe url GET reques, along with the standard fields like EntityID and UserID?
We want to make our iframe endpoint secure without forcing the user to login again to our system (or even the Bullhorn system). Anyone with a copy of the GET request string (MITM, sniffing, logs, etc) can try to replay it / edit it without us being able to determine if the request is good or not. I guess we *could* force non-sequential id numbers to prevent guessing of id's, but that does not stop random replays. We'd like something we can use for authentication.
Perhaps if we could store a public key on Bullhorn, along with a nonce timestamp or auto-incrementing message number, and have it generate security keys for each iframe url GET reques, along with the standard fields like EntityID and UserID?