Attribute mapping validation on PUTs (SAML Epic)
As Identity I want Repose to validate policies for attribute mapping on PUTs so that they customers who now have policies exposed to them aren’t sending in invalid policies.
We are being asked to validate the put of the mapping in to Identity. It's their data. This goes beyond is the request legit, well formed? This is potentially a new filter for Repose using the attribute mapper library.
We also need to know what we're trying to validate exactly? Correctness?
Pending story grooming with Jorge.
1. Customer creates a policy and tries to save it to an IDP.
2. Repose executes the policy later on.
When the customer initially does a PUT, if there's a mistake in the policy format, then error it out.
What's an error in the policy format?
- Malformed JSON
- Problems in the policy language (e.g. not following the rules)
Jorge created in the attribute mapping project called validatePolicy that does the validation of the policy mapping format. What he would like to do is create a JSON Schema in order to provide friendlier error messages (e.g. provide the name of the attribute that has an issue). If Jorge does do this, then it'll be done in that same method (i.e. doesn't change what Repose has to do).
What about stuff that Identity needs (e.g. certain fields)? The validation tries to compile the policy to see if it blows up. From Repose's perspective, all we're doing is (for a certain call), call the new method in the attribute mapping library, then pass the normalized output to the next filter/origin service.
We will be doing this in a new filter and not in the existing SAML policy translation filter.
- The mapping policy for an IDP operation is only validated for PUT operations.
- The method should always be called in the filter (the uri-regex on the filter in the system model is expected to be used).