I am trying to figure out an appropriate and secure design for the following scenario: A user starts out in a "human resources" portal (see payroll info, manage PTO, enroll for insurance benefits, etc). As part of the annual insurance benefits enrollment process, the user must visit the site of an insurance carrier. For that, the HR portal and insurance carrier have implemented a SAML-based redirection, so that the user does not have to separately log into the insurance carrier's site.
In order to execute the ongoing enrollment process, the insurance carrier site requires a rather large set of data about the employee as well as certain enrollment-related information. Some of that data required by the insurance carrier is sensitive data, such as personally identifiable information (PII) or medical information.
One simple way to provide the carrier website with the required data would be to include all this information as assertions in the SAML token that the user's browser presents to the carrier's website during the redirect. However, that will bloat the SAML token, and per guidelines e.g. from Google, SAML tokens should not contain such sensitive data to begin with.
Another option would be that the carrier builds out a web service that accepts the sensitive data required for the enrollment process. The HR portal would call that carrier webservice and transmit all required information before initiating the SAML-based redirection.
1) User initiates "carrier" workflow.
2) HR portal back-end transmits sensitive data to carrier web service. Receives a transmission ID.
3) HR portal acquires SAML token from identity provider, includes transmission ID as assertion.
4) HR portal redirects user to carrier website, presents SAML token.
5) Carrier website looks up transmitted sensitive data for arriving user, by transmission ID from SAML token.
To summarize, the business case I am trying to solve is to provide large amounts of data as well as sensitive data from one company/site to another during a synchronous user workflow that spans both sites. I am sure there are many other, similar scenarios beyond the HR platform + insurance carrier example that I mentioned.
While option #2 is more secure and does not violate guidelines about SAML assertions, it feels too "custom" to me, not using any standard mechanisms. I am wondering if there are better, more standards-based solutions to support this business case. Any thoughts?
PS: I described the redirect and SSO flow with SAML but I am pretty sure the same limitations and recommendations apply in an OAuth2 or OpenID Connect-based flow (sorry, might be using these terms loosely, not an expert in this area).
I suggest option #1 (including all necessary user information as SAML attributes in the SAML assertion) as it's standards based and will work with any SAML compliant partner sites. No proprietary web service and attendant security bearer token etc is required. You could look at a provisioning protocol such as SCIM but this is probably overkill and there's less support for this protocol than SAML.
The SAML response/assertion is sent in an HTTP Post as post data rather than a redirect so there are no practical limitations in the size of the data you send. I wouldn't consider it "bloat" if it's data required by the recipient site (ie service provider). The Google guidelines are more to do with their implementation rather than anything in the SAML specification.
The SAML response should be sent over HTTPS. You also have the option of encrypting the SAML assertion if the user data is particularly sensitive.