rajeshemailto Absent Member.
Absent Member.
1416 views

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

0 Likes
13 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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).
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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).
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

lhaeger;2449327 wrote:
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.)


And which eDir to eDir are you connecting to?

If NAM writes to one eDir store (only writes on the initial federation, after that it just queries for an attribute match rule, doesn't actually submit a create/write/update), then what is an eDir driver going to connect to if there's only one eDir store?

I suppose it could work if you used the internal NAM eDir store (messy, IMO), but I think that requires the custom coding stuff with NAM in order for that to happen.

But I could be wrong.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

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).

🙂
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

On 1/31/2017 3:56 AM, kjhurni wrote:
>


> 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).


I'm happy to talk about writing custom code if you want 😉 You have my
email address


--
Cheers,
Edward
0 Likes
Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

edmaa;2449946 wrote:
On 1/31/2017 3:56 AM, kjhurni wrote:
>


> 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).


I'm happy to talk about writing custom code if you want 😉 You have my
email address


--
Cheers,
Edward


You don't want any Cool Solutions points?

LOL!
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Attributes Not Getting Updated For Federated User Login

On 2/2/2017 7:56 AM, kjhurni wrote:
>
> edmaa;2449946 Wrote:
>> On 1/31/2017 3:56 AM, kjhurni wrote:
>>>

>>
>>> 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).

>>
>> I'm happy to talk about writing custom code if you want 😉 You have my
>> email address
>>
>>
>> --
>> Cheers,
>> Edward

>
> You don't want any Cool Solutions points?
>
> LOL!
>
>


🙂

Just drop me an email

--
Cheers,
Edward
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.