Because schema, object class definitions, etc. are DirContexts in JNDI, the API allows changing them at runtime (adding new attributes, removing them, etc.). Is this supported, or does this depend on repository implementation? In particular, is this supported by LDAP repositories? If it depends on implementation, I am interested in ApacheDS and OpenDJ.
The schema might be mutable: whether or not an LDAP client can change the schema depends on whether the directory administrators allow changes to subschema entries. In some servers, but not all, the location of the schema is listed in the root DSE.
Generally, the schema must be readable since LDAP clients require access to matching rules, ordering rules, and attribute syntaxes to perform comparisons of attribute values (language-native comparisons should be avoided and matching rules should be preferred), but whether the schema is mutable depends on whether the administrators allow it for clients.
see also
LDAP: The Root DSE for more information about the root DSE
Some servers, like OpenDJ, Sun Directory Server..., allows you to dynamically modify the server's schema (provided you have proper permissions), but it is highly recommended that you extend the schema and do not make incompatible changes (such as removing objectClass definition that are currently used by entries).
Related
Is there a way to create an "Alias" or a "soft-link" of a subject in schema registry?
I'm asking this is because for certain kafka topics, they share a common schema
e.g.
topic names:
{env}.{level}.{schema_name}.{producer_name}.{realtime|batch}
schema subject:
{env}.{level}.{schema_name}.{version}
When I set up confluent s3 sink connector, the connector avro converter follows topicNameStrategy to derive schema subject from topic name so the schema name is derived to be {topicName}-value
Is there a way for me to create alias {topicName}-value which actually points to {env}.{level}.{schema_name}.{version} in schema registry? I'm trying to avoid duplicating schemas in schema registry or any significant changes in current kafka topics.
Thanks.
When I set up confluent s3 sink connector, the connector avro converter follows topicNameStrategy
You can set value.converter.value.subject.name.strategy to change that.
But that means you need to write your own class to get custom one not offered by Confluent. Sounds like your producer's are already using the same class to register those formats in the Registry rather than also the default {topic}-value, anyway.
The only way to "alias" is to explicitly make the HTTP requests to PUT a new version of a new subject after GET request against the "original". You aren't duplicating anything more than metadata since the schema will remain the same. The main downside is that there is no "linking" between the "aliases" since such a concept doesn't really exist, and therefore, you need to remember to change all subjects.
Personally, I used the pattern of hard-coding env=DEV/level=FOO/ in the topics.dir setting, then the topic names were underneath that. If you have dynamic values, then put those fields in the record itself, and use S3 Connect's FieldPartitioner to accomplish the same thing
I have an LDAP server (Openldap 2.4.42) which is only accessed with writing rights by a Symfony 2.8 application and reading rights from a 3.2 Shibboleth IDP.
Overnight, without any script in the application needing to do that, some of my user attributes names were changed from Camel to uppercase. For exemple, I had eduPrimaryAffiliation and this morning it had became EDUPRIMARYAFFILIATION.
If any of you could point me in a direction, I will gladly give more information if needed, I think that is the basics needed to study the problem but feel free to ask for more.
Thanks everyone !
I guess you're seeing this upper-case attribute name in output of slapcat. Right?
This usually happens if schema was removed from the OpenLDAP server's configuration and some attributes using this schema are still there. slapcat will then export these attributes with upper-case names (instead of the original camel-cased attribute name in the schema).
We have multiple apps that use OpenLDAP for authentication and for storing data. We have quite lot links to these OpenLDAP entities from DBs from multiple applications (each app has its own DB), so when you change OpenLDAP entity you have to track object changes (currently we are using DN as a reference key). And inside LDAP we have few references, like what user can access which objects, as they can have very specific access rights (access right are not depend on hierarchy), LDAP also doesn't track these changes, so once these referenced objects are moved we need to track them both in LDAP and in multiple DBs.
I'm new to linux and OpenLDAP (we have it running on linux), but to me this all seems like a wrong way to handle things and it seems like we are using LDAP in the way it wasn't designed to be used (The idea of using it like this came from senior developers).
My questions is:
Is there anything bad to use LDAP in way i have described.
How can i change the OpenLDAP schema to create something like GUID for all object classes we are using, this way at least we can store object GUID instead of DN and don't have to track changes. If I change schema will I be able to perform search and filter by this GUID?
Sorry, but your architecture description is not clear for me, so I can't write if it's bad to use it like this.
Having multiple directories in a company is very common in middle to big companies (most of the time it's due to historical reasons) but for single sign on "Meta directories" are setup to have a single authentification point.
In my point of view the DN is obsolutly not the way to point an object in a directory, jus because moving an object is changing his DN. Each directory has got an attribute inherited from the "top" class that contains an unique identifier inside the directory. In OpenLDAP it's entryUUID.
entryUUID: bec561c4-c5b0-102a-81c0-81bc30f92d57
If you want to link datas in a not too big Directory you can also use referential integrity, that the way users are linked to groups (when you move a user you don't have to look at each group it belongs to) in operating systems directories (RefInt Overlay in OpenLDAP).
I have multiple projects in TRAC. I'm using mod_wsgi, and my wsgi script file TRAC_ENV_PARENT_DIR variable is pointing to the folder containing folders with all these projects. A few users have access to different projects. When a user visits the TRAC URL, she can see the listing containing all these projects, yet has no access to some of them.
Is there any way to show to a user only those projects this user has access to?
Please advise.
Preamble: I abhor security through obscurity. Your request could be read as cosmetics in web site presentation. Don't aim at improved access control, because knowing a valid path will still give access to each Trac environment depending on it's settings. Of course better navigation is a good reason.
Requiring to hide folders depending on user's permission means you require authentication before granting access to TRAC_ENV_PARENT_DIR. This could be done with standard mechanisms that your web server supports. This is just the precondition.
As you say, you have some non-public Trac instances in your Trac environment folder collection. How complicated it is to identify all folders correctly, that depends on how much you want to spend on initial implementation vs. maintenance.
I should be trivial, but error-prone, to provide a list of either the public or the private directories, of course whatever is easier to maintain. Zero additional configuration would require to open each Trac environment and look up user permissions. )** This sounds rather cumbersome and means probably a performance penalty for applications with large user base and frequent access. You will at least work with a cached list, if you go down this road.
You can't use Trac's auto-generated Available projects list but you'll have to deliver at least two versions of an index page for authenticated/unprivileged and authenticated and privileged users.
For the sake of maintenability you'll want to consolitate configuration and permissions. For access to each Trac environment you could use trac.ini inheritance and a shared .htpasswd file. However you can't inherit permissions, because these settings are stored inside the Trac db. You could give TracUserSyncPlugin a shot, but it seems not yet fit for production, or at least lacks feedback of all the happy users, if they exist.
)** While I'm not aware of dedicated documentation about this, there are actually several possibilities. Since permissions are stored in the Trac db, all involve reading/querying the permission db table. It's structure is documented with all other tables of the Trac db schema. To read you'll want to open the Trac environment(s) and then use a direct query on the table (see a AccountManagerPlugin changeset for an example) or construct and query a PermissionCache object.
It may be an old question, but so far i've found the answers to be rather complex without need.
I think using the information stated here, http://trac.edgewall.org/wiki/TracInterfaceCustomization#ProjectList , one could build a template that checks for users and permissions and then show the data it should.
In my case, i just needed to point the "TRAC_ENV_INDEX_TEMPLATE" variable to blank HTML, and that was enough for me.
I'm creating a user repository ldap backend for a series of web applications sharing the same users. I would like to store preference information in this ldap location. This way everything related to users is maintained in the same place and can be shared among all applications.
I'm thinking of a general structure like this:
ou=People,dc=domain,dc=com
uid=jdoe,ou=People,dc=domain,dc=com
ou=Preferences,uid=jdoe,dc=domain,dc=com
ou=firstpreference,ou=Preferences,uid=jdoe,dc=domain,dc=com
value : 123
value : 456
I have several questions:
Is jsut below the user entry the right place to start storing the preferences? What objectClass should this entry be? I'm experimenting with organizationalUnit but it doesn't seem right.
What is the best way to store name value pairs for the preferences? Here my best guest is to create an entry just below the preferences having a name and create the value just under it. This way I can account for multiple values. What should be the correct objectClass for those entries?
I'm working with OpenLDAP and wouldn't like to change the schemas that come with it. Is there a way to set this up using available schemas?
You can certainly store preferences as children of the user node. Alternatives would be on the user node itself or in a completely separate branch. Depends on how you will be maintaining it (who will have permissions, how granular the permissions are, how often new preferences and applications will be added, etc).
OU is the wrong object type. You should define your own schema to suit your application. Generally you want to keep schema changes to a minimum, so the schema you define should be designed to be extensible when new preferences / apps are needed.
You can either define an attribute for each preference and use the LDAP server's inbuilt name-value pair support. Or you can define a generic 'preferences' attribute and store the name and value in the data. Again, how you do it depends how many preferences there are, frequency of changes, ability to search and index fields, etc.
There's nothing to stop you using inbuilt types for everything. Just like there is nothing to stop you calling all your variables v1, v2 and your files stuff.txt. But when there aren't any inbuilt types that match your needs, this is the time to add your own. It's a pretty simple thing to do.
I don't think the LDAP directory would be the best place to store this, really. If it's web application preferences, you should store them with and in the web applications - in a shared fashion.
The LDAP directory is concerned with your user accounts, permissions, your organization's structure - I would not recommend putting application-specific settings inside the LDAP directory.
Marc
While LDAP is a versiatile read optimized database as appose to SQL being read/write optimized and NoSQL db's being key-value datastores. LDAP is great for large scale deployment with clustering already in mind that writes once and reads many times. But a use case that has many read/writes for key values then a NoSQL database like redis or memcached is better for basic key value datastores.