locked
Issuance Authorization Rules <> Issuance Transform Rules RRS feed

  • Question

  • I have finally been asked to look into configuring Issuance Authorization Rules.  From what I have read in all of the documents the IAR pipeline functions similar to the Issuance Transform Rules pipeline. 

    What seems strange however is that I have come to the conclusion that any claims added to the ITR pipeline are not visible to the IAR pipeline.  Claims added and/or issued in the ITR pipeline cannot be evaluated in the IAR pipeline and must be re-added and/or re-issued in the IAR pipeline.  Is this a correct understanding if how this flow works?

    I suppose having to re-add and/or re-issue claims in the IAR pipeline isn't that much of a big deal for regular LDAP attributes and what not, but for my scenario where I have written a Custom Attribute Store it means I have to make multiple calls for the same information whenever I add a IAR.  Is this the expected behavior?

    Saturday, February 18, 2017 6:13 PM

Answers

  • There are 3 rules processed when a user is requesting a token, in the following order:

    1. Acceptance transform rules at the Claim Provider trust level. The output of these rules is added to the pipeline.
    2. Issuance Authorization rules at the Relying Party trust level. The purpose of these rules is to issue a Permit claim to be able to continue. The output of the rule 1. are available to be used. Everything collected in these rules will not be injected in the pipeline passed to the next rules.
    3. Issuance Transform rules at the Relying Party trust level. These rules can used what is available in the pipeline (so the output of rules 1. not the output of rules 2.).

    Let say you want to filter access based on an AD group.

    1. The AD groups get into the pipeline. Well the SID of the groups get into it if the claim provider trust is in AD.

    2. You want to allow only users member of GroupA. You don't have the name of the groups in the pipeline. You have the SID of the groups (well you should better use the SID but for the sake of the example, let's do it with the name). You retrieve the name of the groups the user is a member of, put it into the pipeline. And then issue a Permit claim if GroupA is in the list.

    3. You want to add the name of all the group is a member of in the token. You gathered this info already, but in the rules 2. so it is no longer in the pipeline at this stage. Here you will have to query it again.

    Just an example. Hope this helps....


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, February 20, 2017 9:14 PM

All replies

  • Hi Chris! According to the documentation, IAR are processed BEFORE ITR, therefore is it by design that you cannot see any claims from ITR in IAR input.

    You can try to fetch all required attributes at IAR step, then pipe-lining them into ITR. 


    https://exchange12rocks.org/ | http://about.me/exchange12rocks

    Saturday, February 18, 2017 10:56 PM
  • There are 3 rules processed when a user is requesting a token, in the following order:

    1. Acceptance transform rules at the Claim Provider trust level. The output of these rules is added to the pipeline.
    2. Issuance Authorization rules at the Relying Party trust level. The purpose of these rules is to issue a Permit claim to be able to continue. The output of the rule 1. are available to be used. Everything collected in these rules will not be injected in the pipeline passed to the next rules.
    3. Issuance Transform rules at the Relying Party trust level. These rules can used what is available in the pipeline (so the output of rules 1. not the output of rules 2.).

    Let say you want to filter access based on an AD group.

    1. The AD groups get into the pipeline. Well the SID of the groups get into it if the claim provider trust is in AD.

    2. You want to allow only users member of GroupA. You don't have the name of the groups in the pipeline. You have the SID of the groups (well you should better use the SID but for the sake of the example, let's do it with the name). You retrieve the name of the groups the user is a member of, put it into the pipeline. And then issue a Permit claim if GroupA is in the list.

    3. You want to add the name of all the group is a member of in the token. You gathered this info already, but in the rules 2. so it is no longer in the pipeline at this stage. Here you will have to query it again.

    Just an example. Hope this helps....


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, February 20, 2017 9:14 PM