locked
Max number of claim rules in a relying party trust RRS feed

  • Question

  • Hi,

    ADFS v.4 (Server 2016)

    Is there a limit to the maximum number of claim rules a single relying party trust can accommodate?  Sample scenario = a service provider grants authorization to various parts of their application based upon user's membership in an AD group (IdP side).  Potentially 100 unique roles have been identified.  For sake of this question, please assume that the group claim is the only possible solution at present.

    Thanks for your time,

    DaveC

    Friday, November 16, 2018 5:15 PM

Answers

  • Actually in your case the claim type is static. 

    1. Have a rule that add the groups' names into a temporary claim:

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
     => add(store = "Active Directory", types = ("temp:claims/groups"), query = ";tokenGroups;{0}", param = c.Value);

     2. Then if the group name matches the pattern <string1>_<string2>_<role identifier> then we extract the <role identifier> and send it as a Role claim type (http://schemas.microsoft.com/ws/2008/06/identity/claims/role):

    c:[Type == "temp:claims/groups", Value =~ "^.+?(?=_).+?(_).*$"]
     => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = regexreplace(c.Value, "^.+?(?=_).+?(_)(?<role>.*)$", "${role}"));
    

    We can customize the second rule to consider the group only if <string1> and/or <string2> also match a speficic pattern. So give it a try and let us know.


    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.

    Friday, November 23, 2018 2:42 PM

All replies

  • Common sense would be the limit :) You can use dynamic claims type too. So technically for 100 roles you can still have only one rule. If you have more details on the groups, roles and claim types you need, we can come up with examples.


    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.

    Saturday, November 17, 2018 2:13 AM
  • Thanks Pierre  :)

    Initially, the design is:

    Claim type will be "Application/Role"

    Claim values will be a role identifier of the form "xxx0001", "xxx0002", etc...

    The group names will use the naming standard "<string>_<string>_<role identifier>", such that the last portion of that name will contain the role identifier to be passed as the claim value for "Application/Role".

    Do dynamic claims necessitate leveraging a custom attribute store to help build the values?

    -DaveC

    Saturday, November 17, 2018 1:56 PM
  • Actually in your case the claim type is static. 

    1. Have a rule that add the groups' names into a temporary claim:

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
     => add(store = "Active Directory", types = ("temp:claims/groups"), query = ";tokenGroups;{0}", param = c.Value);

     2. Then if the group name matches the pattern <string1>_<string2>_<role identifier> then we extract the <role identifier> and send it as a Role claim type (http://schemas.microsoft.com/ws/2008/06/identity/claims/role):

    c:[Type == "temp:claims/groups", Value =~ "^.+?(?=_).+?(_).*$"]
     => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = regexreplace(c.Value, "^.+?(?=_).+?(_)(?<role>.*)$", "${role}"));
    

    We can customize the second rule to consider the group only if <string1> and/or <string2> also match a speficic pattern. So give it a try and let us know.


    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.

    Friday, November 23, 2018 2:42 PM
  • Sorry for my delayed reply.  Pretty cool - I didn't realize that the tokenGroups query would return group NAMES (instead of SIDs), so I'll test this out and follow up.

    -DaveC

    Tuesday, December 11, 2018 10:52 PM
  • Hi Pierre/all,

    I customized the REGEX [suggested earlier] a bit to accommodate recent changes in our method here, but the crux of the matter in general is this --> using tokenGroups in the query filter is the important bit which enables this solution to work very nicely.

    As stated in my last post, I had assumed tokenGroups would just return SIDs so never bothered trying that until suggested by Pierre.

    Many thanks!

    -DaveC

    Thursday, December 20, 2018 5:30 PM