MinIO

12513 Commits

4 Branches

520 Tags

175 MiB

Branch: master

Commit Graph

Author	SHA1	Message	Date
Harshavardhana	8ce101c174	fix: LDAP service port number in tests	9 months ago
Poorna	e947a844c9	Fix test scripts to use mc ready (#19768 )	1 year ago
Aditya Manthramurthy	3212d0c8cd	fix: IAM import for LDAP should replace mappings (#19607 ) Existing IAM import logic for LDAP creates new mappings when the normalized form of the mapping key differs from the existing mapping key in storage. This change effectively replaces the existing mapping key by first deleting it and then recreating with the normalized form of the mapping key. For e.g. if an older deployment had a policy mapped to a user DN - `UID=alice1,OU=people,OU=hwengg,DC=min,DC=io` instead of adding a mapping for the normalized form - `uid=alice1,ou=people,ou=hwengg,dc=min,dc=io` we should replace the existing mapping. This ensures that duplicates mappings won't remain after the import. Some additional cleanup cases are also covered. If there are multiple mappings for the name normalized key such as: `UID=alice1,OU=people,OU=hwengg,DC=min,DC=io` `uid=alice1,ou=people,ou=hwengg,DC=min,DC=io` `uid=alice1,ou=people,ou=hwengg,dc=min,dc=io` we check if the list of policies mapped to all these keys are exactly the same, and if so remove all of them and create a single mapping with the normalized key. However, if the policies mapped to such keys differ, the import operation returns an error as the server cannot automatically pick the "right" list of policies to map.	1 year ago

Author

SHA1

Message

Date

Harshavardhana

8ce101c174

fix: LDAP service port number in tests

9 months ago

Poorna

e947a844c9

Fix test scripts to use mc ready (#19768 )

1 year ago

Aditya Manthramurthy

3212d0c8cd

fix: IAM import for LDAP should replace mappings (#19607 )

Existing IAM import logic for LDAP creates new mappings when the
normalized form of the mapping key differs from the existing mapping key
in storage. This change effectively replaces the existing mapping key by
first deleting it and then recreating with the normalized form of the
mapping key.

For e.g. if an older deployment had a policy mapped to a user DN -

`UID=alice1,OU=people,OU=hwengg,DC=min,DC=io`

instead of adding a mapping for the normalized form -

`uid=alice1,ou=people,ou=hwengg,dc=min,dc=io`

we should replace the existing mapping.

This ensures that duplicates mappings won't remain after the import.

Some additional cleanup cases are also covered. If there are multiple
mappings for the name normalized key such as:

`UID=alice1,OU=people,OU=hwengg,DC=min,DC=io`
`uid=alice1,ou=people,ou=hwengg,DC=min,DC=io`
`uid=alice1,ou=people,ou=hwengg,dc=min,dc=io`

we check if the list of policies mapped to all these keys are exactly
the same, and if so remove all of them and create a single mapping with
the normalized key. However, if the policies mapped to such keys differ,
the import operation returns an error as the server cannot automatically
pick the "right" list of policies to map.

1 year ago

3 Commits (master)