Question about Scripted attribute in attribute-resolver.xml

[Emilie Boulard]

Hello Scott, 

Thanks for your answer.

I did initially though of using a secondary DN in the ldap.properties so i could access to the right ldap attribute in the correct OU.
But when trying that i realised it was impacting authentification and that's not what i want. Our users must identify whith their ldap login.

This is why i tried to manipulate the attribute i got from my ldap DN defined in my DataConnector.

I know how to get the information with a ldapsearch request but what i don't know is to implement that in an attribute definition in my attribute-resolver.

But as reading your answer, i guess this is not a possibility or a best pratice.

Just for understanding, when you say: 

> - look for a Java library from a third party that perhaps supplies that kind of functionality so you can script against it

It means that it is possible to use and import some other java library in a Attribute definition ?

> - back off and accept that hardcoding the information into a local map is a better option

Do you mean as a local data connector to get the attribute?


Sorry for my newbies questions, i have been on Shibboleth only for 15 days so i am still learning!


Thansk again and have a nice day, 

Emilie



----- Mail original -----
De: "Cantor, Scott via users" <users at shibboleth.net>
À: "Shib Users" <users at shibboleth.net>
Cc: "Scott Cantor" <cantor.2 at osu.edu>
Envoyé: Jeudi 29 Février 2024 23:40:49
Objet: Re: Question about Scripted attribute in attribute-resolver.xml

> So i thought maybe i am doing this the wrong way and try to made
> something more complicated than needed.

What you're trying is...out of the question IMHO.

If Java doesn't have a way of bypassing portability and interrogating the /etc/groups (etc.) files to get the information, I would probably consider a couple of options:

- look for a Java library from a third party that perhaps supplies that kind of functionality so you can script against it

- back off and accept that hardcoding the information into a local map is a better option

Honestly, using Unix uid/gid information is a really bad practice anyway, it's not meaningful when it literally depends on the machine you're on, it's not a fixed sort of mapping. It sounds like the problem is with the underlying approach and data you're dealing with.

-- Scott


-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net