Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Random ADFS notes

(Nothing new here. I was taking notes when reading up while troubleshooting an issue). 

All incoming rules can be thought of as being stored in an input rules set. 

All the claim rules are in a claim rule set. 

All rules in the claim rule set share the same input rules set. Each claim rule can also add to the shared input claim set, which can be used by subsequent rules. 

The claims created from claim rules are stored in an output claim set. This is initially empty, and is populated as the rules are processed. The claims in the output claim set are what is output when execution completes. 

Claim rules are processed top to bottom as per the list. 

Claim rules are of the format Condition statement => issuance statement;

The output of a claim rule can be to either both the input & output claim set, or only to the input claim set. If the issuance statement has an add statement it is to the input claim set only; if it has an issue statement it is to both. 

Condition syntax examples here. Key takeaways:

  • You can add or issue claims as mentioned earlier. 
  • In either case you can have Normal issuance statements that (a) creates a copy of an existing claim to the output set (am not sure how this works, I can’t think of an example) or (b) creates a new claim based on values in the input claim set (these should have the claim type specified for the new claim). 
  • You can also have Attribute Store issuance statements. In a single issuance statement you can create multiple claim types or multiple claims for a given type. The attribute store will have a query syntax. See here for examples. 
  • Both condition and issuance statements make use of expressions. 
  • Regex too is supported
  • Here are some of the claim properties available: type, value, issuer, originalissuer, valuetype. 
  • Apart from matching on == (equals, case sensitive) one can also match on != (not equals, case sensitive), =~ (regex match, case sensitive), and !~ (regex non match, case sensitive). Add a (i) to make it non case sensitive. 

It is important to remember that you can’t discard claims. As in, if the input set has a claim A and you do some modifications (transforms) to it, then both claim A and the modified claim A are passed on. This doesn’t make a 100% sense to me because I get the impression from the EXISTS function that you can discard claims. I think that applies more to temporary claims you create via the add statement.

(Update: I remembered later what I was trying to convey here. Say you have a claim rule that passes all incoming claims. Then you have other claim rules that maybe modifies one of these claims. You would think that this being a pipeline only the modified claim will be passed out, the original claim will stay as it is. But nope. Because the first claim rule was issuing all incoming claims the original claim too is passed along with the modified claim. Thus it is (a) better to not blindly pass all incoming claims and (b) if you want to make changes to an incoming claim don’t issue it, rather add it, modify, and then issue. )

Some more links:

Random ADFS notes by rakhesh is licensed under a Creative Commons Attribution 4.0 International License.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

  

  

  

This site uses Akismet to reduce spam. Learn how your comment data is processed.