Attributes Not Getting Updated For Federated User Login


Hello,

Component OS Version Other Info
Admin Console 4.1.2.0-23
Identity Server Linux 4.1.2.0.23-04C4ECDBE8F42714
Access Gateway Linux 4.1.2.0-23-645018B56630115F 4.1.2.0.23
(Service Provider)


*Configuration*: Identity Servers > [Cluster] > SAML2.0 > Identity
Provider [idp] > Configuration > User Identification > Provisioning
Setting. We’ve mapped all SAML attributes to eDir attributes.


*Scenario*: When user first login via SAML v2, we have provisioning SAML
configured with provisioning setting which creates user successfully in
IDP. But when we change first name of the user in SAML system or any
other valid mapped attribute and try to login again, new value doesn’t
update on IDP\IDVault.

Not sure as if this is how NAM works or some more config is required.


--
rajeshemailto
------------------------------------------------------------------------
rajeshemailto's Profile: https://forums.netiq.com/member.php?userid=196
View this thread: https://forums.netiq.com/showthread.php?t=57208

  • On 1/18/2017 7:47 PM, rajeshemailto wrote:
    >
    > Hello,
    >
    > Component OS Version Other Info
    > Admin Console 4.1.2.0-23
    > Identity Server Linux 4.1.2.0.23-04C4ECDBE8F42714
    > Access Gateway Linux 4.1.2.0-23-645018B56630115F 4.1.2.0.23
    > (Service Provider)
    >
    >
    > *Configuration*: Identity Servers > [Cluster] > SAML2.0 > Identity
    > Provider [idp] > Configuration > User Identification > Provisioning
    > Setting. We�ve mapped all SAML attributes to eDir attributes.
    >
    >
    > *Scenario*: When user first login via SAML v2, we have provisioning SAML
    > configured with provisioning setting which creates user successfully in
    > IDP. But when we change first name of the user in SAML system or any
    > other valid mapped attribute and try to login again, new value doesn�t
    > update on IDP\IDVault.
    >
    > Not sure as if this is how NAM works or some more config is required.


    This is working as designed. NAM doesn't update the attributes of a
    provisioned account if a subsequent SAML token contains different values.

    If you want to do that you really want an Identity Management solution.


    --
    Cheers,
    Edward
  • edmaa;2449013 wrote:
    On 1/18/2017 7:47 PM, rajeshemailto wrote:
    >
    > Hello,
    >
    > Component OS Version Other Info
    > Admin Console 4.1.2.0-23
    > Identity Server Linux 4.1.2.0.23-04C4ECDBE8F42714
    > Access Gateway Linux 4.1.2.0-23-645018B56630115F 4.1.2.0.23
    > (Service Provider)
    >
    >
    > *Configuration*: Identity Servers > [Cluster] > SAML2.0 > Identity
    > Provider [idp] > Configuration > User Identification > Provisioning
    > Setting. We�ve mapped all SAML attributes to eDir attributes.
    >
    >
    > *Scenario*: When user first login via SAML v2, we have provisioning SAML
    > configured with provisioning setting which creates user successfully in
    > IDP. But when we change first name of the user in SAML system or any
    > other valid mapped attribute and try to login again, new value doesn�t
    > update on IDP\IDVault.
    >
    > Not sure as if this is how NAM works or some more config is required.


    This is working as designed. NAM doesn't update the attributes of a
    provisioned account if a subsequent SAML token contains different values.

    If you want to do that you really want an Identity Management solution.


    --
    Cheers,
    Edward


    I thought there was a way (sorta kinda) if you wrote your own code or used custom variables. I vaguely recall asking Neil about this a while ago (like 2 years ago) and it was doable, but not in a way we desired. Even with an IDM solution, you'll still have to figure out how to get the information from the SAML assertion sent to NAM to the IDM eDir driver in order to update the object. I don't think that's "native" in the authorization or redirection policy engine (if SAML assertion attribute BLAH is different than LDAP attribute BLAH, then redirect to IDM UA, for example).
  • On 1/20/2017 1:56 AM, kjhurni wrote:
    >


    > I thought there was a way (sorta kinda) if you wrote your own code or
    > used custom variables. I vaguely recall asking Neil about this a while
    > ago (like 2 years ago) and it was doable, but not in a way we desired.
    > Even with an IDM solution, you'll still have to figure out how to get
    > the information from the SAML assertion sent to NAM to the IDM eDir
    > driver in order to update the object. I don't think that's "native" in
    > the authorization or redirection policy engine (if SAML assertion
    > attribute BLAH is different than LDAP attribute BLAH, then redirect to
    > IDM UA, for example).
    >
    >


    I vaguely remember having a discussion with you about this and having to
    write a post authentication class but I reckon it would be messy. A IDM
    solution would be a better option.

    --
    Cheers,
    Edward
  • edmaa;2449199 wrote:
    On 1/20/2017 1:56 AM, kjhurni wrote:
    >


    > I thought there was a way (sorta kinda) if you wrote your own code or
    > used custom variables. I vaguely recall asking Neil about this a while
    > ago (like 2 years ago) and it was doable, but not in a way we desired.
    > Even with an IDM solution, you'll still have to figure out how to get
    > the information from the SAML assertion sent to NAM to the IDM eDir
    > driver in order to update the object. I don't think that's "native" in
    > the authorization or redirection policy engine (if SAML assertion
    > attribute BLAH is different than LDAP attribute BLAH, then redirect to
    > IDM UA, for example).
    >
    >


    I vaguely remember having a discussion with you about this and having to
    write a post authentication class but I reckon it would be messy. A IDM
    solution would be a better option.

    --
    Cheers,
    Edward


    I don't think you can resolve this solely with IDM. Since the SAML assertion with the attribute data is coming in through NAM, you'd still need *some* way to submit that information to any IDM engine driver somehow.

    So that would mean that NAM would still have to somehow be able to determine what's submitted is different than what's already there and then submit that information (probably with the custom post auth class stuff), but if you're going to go that far, you don't even need IDM then, IMO.

    Otherwise you'd still have to figure out how to get NAM to *always* submit all the attribute information it receives via SAML to an IDM driver and then let it figure out if there's a modification involved, but that seems highly inefficient.

    But I'm sure it could technically be done, but the underlying "controlling" thingy is NAM in this case, so you're still going to have to do work there, IMO. I don't see any way to not involve NAM and rely 100% on an IDM driver in that case. NAM gets the assertion attribute information and either:
    a) has to always pass that info to an IDM driver somehow
    or
    b) determine if/what is changing and then submit to IDM driver somehow
    or
    c) determine if/what is changing and update eDir directly.

    At least if you want an automated method of doing it. The few places I've seen take a manual approach where the user has to update their own information in each "place" (ie, use Google's tools to update the stuff there, then use Company ABC IDM product to update the federated information there as well).
  • On 1/21/2017 7:06 AM, kjhurni wrote:
    >


    > At least if you want an automated method of doing it. The few places
    > I've seen take a manual approach where the user has to update their own
    > information in each "place" (ie, use Google's tools to update the stuff
    > there, then use Company ABC IDM product to update the federated
    > information there as well).
    >
    >


    You'd put a driver between the source system (the identity provider) and
    the directory NAM provisions the object in.

    --
    Cheers,
    Edward
  • edmaa;2449268 wrote:
    On 1/21/2017 7:06 AM, kjhurni wrote:
    >


    > At least if you want an automated method of doing it. The few places
    > I've seen take a manual approach where the user has to update their own
    > information in each "place" (ie, use Google's tools to update the stuff
    > there, then use Company ABC IDM product to update the federated
    > information there as well).
    >
    >


    You'd put a driver between the source system (the identity provider) and
    the directory NAM provisions the object in.

    --
    Cheers,
    Edward


    There's a SAML driver for IDM?

    Third party IDP -> NAM SP which then federates into eDir/whatever.

    Or are you talking specifically for say Google vs. some other IDP?
  • kjhurni wrote:

    > There's a SAML driver for IDM?


    NAM uses Edirectory as it's backend, so can choose between two flavors of
    edir2edir driver (and probably native LDAP as a third option).

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 1/24/2017 2:56 AM, kjhurni wrote:
    >
    > There's a SAML driver for IDM?
    >
    > Third party IDP -> NAM SP which then federates into eDir/whatever.
    >
    > Or are you talking specifically for say Google vs. some other IDP?


    No, it has nothing to do with SAML anymore. Its just a direct driver
    between what system the IDP has and the user store that you use for NAM.
    Depending on the identity management solution this would be via a meta
    directory (identity vault) or something other solution.


    --
    Cheers,
    Edward
  • edmaa;2449355 wrote:
    On 1/24/2017 2:56 AM, kjhurni wrote:
    >
    > There's a SAML driver for IDM?
    >
    > Third party IDP -> NAM SP which then federates into eDir/whatever.
    >
    > Or are you talking specifically for say Google vs. some other IDP?


    No, it has nothing to do with SAML anymore. Its just a direct driver
    between what system the IDP has and the user store that you use for NAM.
    Depending on the identity management solution this would be via a meta
    directory (identity vault) or something other solution.


    --
    Cheers,
    Edward


    Right, but my point being (if you see the data flow above) is that NAM is still needed to somehow "trigger" an update.

    If you are using this scenario:

    Third party IDP -> (via SAML HTTP POST Binding) to NAM IDS which is functioning as a SAML SP -> Federation/matching -> eDirectory

    Then, you're still going to need *some* method for NAM to tell eDirectory that the attributes are updated. Normally, after initial federation (assuming permanent,else it's pointless to need updating), NAM will then use an attribute match and that's it. It (NAM) doesn't try or send all the assertion attributes on a match, so eDir isn't going to "see" that attribute XYZ needs updating because NAM is simply going to do (basically) an LDAP lookup for attribute XYZ and if it matches, then that's it.

    You'd need *some* way at that point for IDM to get all the SAML attributes and then figure out if something needs updating or not.

    The only way I know of for that to happen is to use custom code in NAM to force that.

    Not saying it can't be done, but that:

    a) Will require NAM
    b) Will require custom code
    c) Will require IDM

    But if you can do that with just "a" and "b" why complicate things (plus cost) with IDM. Unless IDM is actually needed in addition to a b.

    But again, I could be wrong. Would be nice if someone's actually written/done this with NAM/eDir as maybe a POC or real-life implementation. Right now it's all theory (LOL).

    :)
  • edmaa;2449355 wrote:
    On 1/24/2017 2:56 AM, kjhurni wrote:
    >
    > There's a SAML driver for IDM?
    >
    > Third party IDP -> NAM SP which then federates into eDir/whatever.
    >
    > Or are you talking specifically for say Google vs. some other IDP?


    No, it has nothing to do with SAML anymore. Its just a direct driver
    between what system the IDP has and the user store that you use for NAM.
    Depending on the identity management solution this would be via a meta
    directory (identity vault) or something other solution.


    --
    Cheers,
    Edward


    Right, but my point being (if you see the data flow above) is that NAM is still needed to somehow "trigger" an update.

    If you are using this scenario:

    Third party IDP -> (via SAML HTTP POST Binding) to NAM IDS which is functioning as a SAML SP -> Federation/matching -> eDirectory

    Then, you're still going to need *some* method for NAM to tell eDirectory that the attributes are updated. Normally, after initial federation (assuming permanent,else it's pointless to need updating), NAM will then use an attribute match and that's it. It (NAM) doesn't try or send all the assertion attributes on a match, so eDir isn't going to "see" that attribute XYZ needs updating because NAM is simply going to do (basically) an LDAP lookup for attribute XYZ and if it matches, then that's it.

    You'd need *some* way at that point for IDM to get all the SAML attributes and then figure out if something needs updating or not.

    The only way I know of for that to happen is to use custom code in NAM to force that.

    Not saying it can't be done, but that:

    a) Will require NAM
    b) Will require custom code
    c) Will require IDM

    But if you can do that with just "a" and "b" why complicate things (plus cost) with IDM. Unless IDM is actually needed in addition to a b.

    But again, I could be wrong. Would be nice if someone's actually written/done this with NAM/eDir as maybe a POC or real-life implementation. Right now it's all theory (LOL).

    :)