SAMLv2 Autofederate Attribute Not Clear…

This topic has 3 replies, 2 voices, and was last updated 5 years, 9 months ago by Peter Major.

  • Author
  • #14889


    Unlike a typical IDM scenario ours is such that the IDP does not flow any user profile information to the IDP Proxy / SPs. The only thing it does flow is a unique id and our IDP Proxy / SP needs to generate a user profile random uid.

    Autofederate attribute docs state in part “If the local user can not be found and Dynamic or Ignored Profile is enabled, >>the value will be used as the local user’s UID instead<<”

    Can someone please explain what between >> and << in the above mean and why this done?

    Thank You,


     Peter Major

    Auto federation can be used to simplify the authentication process on the SP side. The account mapper will attempt to figure out the identity of the end-user associated with the assertion based on the attributes/NameID provided. When dynamic or ignored profile is in use, the user profile does not have to actually exist at the SP side, hence you are free to use the value determined by auto federation, it will not cause any problems.


    Hi Peter,

    That is a great explanation and to be honest I get all that it is just the language between >> << that isn’t clear.

    In re-reading it I presume it means that in the case of Dynamic or Ignored that instead of simply using the NameID to federate that it will use this autofederate attribute and assign its value from the assertion to the uid field of the user persisted to the DataStore and session if its Dynamic and only session if it is ignored e.g. autofederate attribute set to “employeenum” and employeenum=5 in assertion so user set with uid=5. Is that correct?

    In addition, if I am using “ignored” at an IDP Proxy and in the IDP Proxy “SP” configuration set autofederate to true and the autofederate attribute to say “employeenum” then the SP will receive an assertion with a user with uid=<employeenum>. Is that correct?

    Much Appreciated!


     Peter Major

    If the auto federation attribute is set to employeenumber, then the default account mapper implementation will look for an Attribute element in the SAML assertion that contains the employeenumber attribute. If the value in the assertion for the employeenumber was 5, then the mapper will look for a user with employeenumber=5 in the configured data stores. If the user cannot be found and dynamic/ignored profile mode is enabled, it will then just use “5” as the username.
    If you had dynamic mode enabled then most likely a user entry will be created in the data store with the user ID 5, but how exactly that’s going to happen, I’m not entirely sure, and probably is very much dependent on what other attributes you receive in the assertion and how you have your data store configured. I would suggest to test this scenario to ensure that it is doing exactly what you wanted it to.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?