Rabbit Eight Brother Note 10: WEBLOGIC's Built-in LDAP Control Access Syntax
These days in studying the use of WebLogic Server LDAP Server, there is a built-in LDAP Server in WebLogic Server, of course, you can also use WebLogic Server to integrate third-party LDAP Server, such as Open LDAP, Netscape Iplanet, Microsoft's Active Directory and Novell NDS Stores.
In addition to Open LDAP, several third-party LDAP Server except Open LDAP, only a Spanish version of IPlanet usage is available on Sun's website. Because I don't have these third-party LDAP Server, I have been using WLS built-in LDAP Server these days.
LDAP's Chinese data is very small, I only found two translated articles, but did not solve my problem, so I read English every day in these days. My ultimate goal is to use LDAP Server to store user information, and then can control it through JNDI, now I am initially implementing data that can insert a custom object class to built-in LDAP.
You may feel that this is nothing, it is indeed. But if you don't have LDAP knowledge, you can change or insert data in the LDAP Server built in WLS in the case of no one, it is likely that you will be very discouraged! I have come like this these days.
The problems I have encountered these days are as follows:
1. How can I see the contents of the built-in LDAP Server? Use the LDAP BROWER to solve this problem.
2. How to connect to the built-in LDAP Server? This requires configuring the connection parameters.
3. How to change, add, delete the value of the attibute of LDAP Server? This is also operated by LDAP Brower, but you want to modify your current access to users' permissions. Of course, you can also write your program.
4. How to define an ObjectClass object, add a custom property to this object, and then read and write it via LDAP BROWER or program? I have found an operational measures through LDAP BROWER.
5. How to use JNDI to read and write LDAP Server? This is my work next week. ^ _ ^.
I will explain the solution to these issues in subsequent notes.
I feel that I should take out what I have seen in these days and I have to share it with others, so I started from this translated article.
WLS's acls.prop is permission to control the user of LDAP. All of the ACLS.Prop of WLS's built-in LDAP Server is commented, so when you connect through the LDAP Brower, you can only use admin to connect, and no properties can be modified. If you want to modify the value of the attribute of the entry, then you should learn about the syntax configured access control file. The following article is about this part.
The following part is the help of the translated BEA WebLogic. I am very annoyed when I translate this article, because there are many long sentences, and I am not familiar with the basic knowledge of LDAP, and there is no books about LDAP, and some terms have not been unified. So I It is recommended that if you look at the article I translated, I feel that I am talking nonsense, and it is likely to be in his words, then I suggest you take a look at the original, ^ _ ^.
Original location: http: //edocs.bea.com/wls/docs81/secmanage/ldap.html# 1101845
Original copyright belongs to BEA.
WebLogic's built-in LDAP Server supports the control access model that IETF LDAP is LDAPv3. This piece below will tell how to implement control accesses in built-in LDAP Server. These rules can be applied directly to the entry of the directory by editing access control files. The access control file in WebLogic is acls.prop. This file can be found in the server's LIB. All access control rules for this file are commented. If you want to change these rules, you have to change this file. Note: WebLogic Server's built-in LDAP Server is only allowed by ADMIN account by default. WebLogic Server's Security Providers uses the admin account to access built-in LDAP Server. If you don't want to use the external LDAP Brower to access the built-in LDAP Server of WebLogic Server, or you just want to use the admin account to access the built-in LDAP Server, you don't need to edit the acls.prop file, then you can skip this section (for this Notes, you can't see it).
Access Control File (The Access Control File)
Access Control File (ACLS.Prop) contains a complete access control list (ACL) of the entire directory of the built-in LDAP Server. Each line in this file contains an access control rule. An access control rule consists of part below:
Ø Location of the LDAP directory of the application rule
Ø Scope of application rules
Ø Access authority (GRANT or DENY)
Ø License (GRANT or DENY)
Ø Application Rules' Attributes (Attribute)
Ø Allow or refuse access to the subject (SUBJECT)
Below is a piece of access to the control file:
[root] | Entry # grant: r, b, t # [all] #public
OU = Employees, DC = OCTETSTRING, DC = COM | Subtree # grant: r, c # [all] #public:
OU = Employees, DC = OCTETSTRING, DC = COM | Subtree # Grant: B, T # [Entry] #public:
OU = Employees, DC = OCTETSTRING, DC = COM | Subtree # deny: r, c # Userpassword # public:
OU = Employees, DC = op | Subtree # grant: r # Userpassword # this:
OU = Employees, DC = op | Subtree # Grant: W, O # Userpassword, Title,
Description,
Postaladdress, Telephonenumber # this:
CN = Schema | Entry # grant: r # [all] #public:
Access Control Location
Each access control rule is applied to a given location in the LDAP directory. This location is usually a distinct naming (DN), but there is an exception, this is [root], if the access control rule is applied to the entire directory, only the specified location is [root]!
This access control rule will not be performed if the location of the entry that is accessed or changed is not equal to the location specified by the access control rule, or the subordinates of the location specified by the access control rule.
Access Control Scope
There are two access control ranges: Entry-an access control list of an Entry range is only performed in the case:
The DN of the entry of the LDAP directory is the same as the location specified by the access control rule. Such rules are very useful for individual entrances that contain more sensitive information than parallel and secondary entrances.
Subtree- means that the location and subtots specified by access control rules can apply this rule.
If Entry has conflicts with Subtree conflicts in the access control rules, Entry should take precedence over Subtree.
Access Rights
Access rights apply to the properties of the entire object or object, 2 values: GRANT or DENY (rejection). Access rights specify the type of LDAP operation.
Attribute Permissions
Abbreviation and significance
Description
R Read
Read. If Grand is allowed, it is allowed to be included in a search operation.
w wh
Change or add. If Grand, Allow properties, is allowed to be included in one change operation.
o Obliterate
Change or delete. If Grand is allowed to be included in a changing operation.
S Search
Search for the entry specified attribute. If Grand, Allow attributes and values are included in a search operation.
c compare
Compare attributes. If Grand, allows properties and values to appear in the comparison operation.
m make
Create a new entry attribute under the current entrance
When all attributes are placed in an object, M is required when this object is created. The positive image W and O are used in the change operation, and M is used in the Add operation.
W is not responsible for add operation, M is not responsible for changing the operation.
Because the new object does not exist, A and M need to create it, but must give the parent class for the new object.
This is different from W and O, W and O must be GRANT to objects being changed.
Because ms have obvious differences between W, O, there is no conflict when adding a child object or inlet and changing a child object or inlet.
In order to successfully replace the value during use, the user must have the permissions of W and O at the same time.
Entry Access License (Entry Permissions)
The following license is applied to access throughout LDAP.
Abbreviation and significance
Description
a Add add an entry in the current entry, If granted, permits creation of an entry in the DIT subject to control on all attributes and values placed on the new entry at the time of creation. In order to add an entry, permission must also be granted to add at least the mandatory attributes. d delete Deletes the current entry. If granted, permits the entry to be removed from the DIT regardless of controls on attributes within the entry. e export inlet and all sub-inlet exported to a new position. If granted, permits an entry and its sub entries (if any) to be exported;. That is, removed from the current location and placed in a new location subject to the granting of suitable permission at the destination If the last RDN is changed, Rename permission is also required at the current location. In order to export an entry or its subentries, there are no prerequisite permissions to the contained attributes, including the RDN attribute. This is true even when the operation causes new attribute values to be added or Removed as the result of the change to the rdn. I Import imports the entry and all sub-inlets and properties from the specified location.
If granted, permits an entry and its subentries (if any) to be imported;. That is, removed from one other location and placed at the specified location (if suitable permissions for the new location are granted) When importing an entry or its subentries , there are no prerequisite permissions for the contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed DN as the result of the changes of RDN. n RenameDN change an LDAP entry. Granting the Rename permission is necessary for an entry to be renamed with a new RDN, taking into account consequential changes to the DN of subentries. If the name of the superior entry is unchanged, the grant is sufficient. When renaming an entry, there are no prerequisite permissions to contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN. b BrowseDN a browser DN entry. If g ranted, permits entries to be accessed using directory operations that do not explicitly provide the name of the entry. t ReturnDN allow inlet DN returned to the client as a result of the operation. If granted, allows the distinguished name of the entry to be disclosed In The Operation Result. Attributes Types
[entry] means that it is allowed to operate the entire object, such as deleting objects or add sub-objects, so its value can only be A, D, E, I, N, B, T.
[All] Application range is all attributes of the entrance, so it can only be one or more of R, W, O, S, C, M.
If the keyword [all] and other attributes in the ACL are specified simultaneously, follow the access control rules specified by the property, because the rules specified by [all] are not as specified in the property.
Subject Types
Access control rules can be associated with a number of Subject types. The Subject of the Access Control Rule decides whether access control rules apply to the current connection.
Here is the type of Subject:
§ Authzid- is applied to a single user that can be part of the Subject definition. The user in the LDAP directory is defined as a DN.
§ Group-Application to a group of users specified as the following object classes
· Groupofuniquenames
· GroupOfnames · Groupofuniqueurls
The first 2 types contain user lists, and the last type allows the user to be included in the group, which is automatically established in the defined standard.
§ Subtree- is applied to DNs as part of the sub-inlet in the Subject and the LDAP directory tree.
§ IP address - Apply to the specified IP address. This subject type is useful in the following cases: all access is applied by a proxy server or other server, applied to a specified host, not a subnet Range.
§ Public- Allows to connect to anyone in this directory, regardless of whether the connector is authorized.
§ This- is applied to the case where the access entry is matched to the user's DN.
GRANT / DENY Evaluation Rules (Grant / Deny Evaluation Rules)
The client sends a request to access the entry information. LDAP Server allows or rejects this request to meet many factors. If the entrance is protected, access rules, etc. Here is a description:
(1) More detailed rules take precedence over other rules.
(2) If the conflict still exists, the Subject rule will determine which rule is applied. Priority order from high to low: IP address-authzid or this-group-subtree or public
(3) When there is a conflict in the ACL, Deny takes precedence over GRANT
(4) If the access control rule is not defined, DENY is the default value, and the access rule of the other entrance should take precedence over the Subtree's access rules of the entrance.
Below is the default ACLS.Prop of WLS8.1 comes with:
# Acls - for more info on acl syntax, refer to the Weblogic Server System Administration
# Guide
#
# The default configuration is an es Empty file (nothing uncommeted). This Denies
# Access to everyone Except The Admin Dn. Users May Be Able To Bind, But Can
# NOT ot s e.
#
# If you wish to enable Additional Access, Choose One of the Following Configurations,
# and uncomment the acl syntax by removing the '#'
#
# 7.0 Configuration - Allows Read Access to Everyone and Write Access To OWN User Info
#
# [root] | Entry # Grant: s, r, b, t # [all] #public
# [root] | Subtree # Grant: s, r, c # [all] #public:
# [root] | Subtree # Grant: B, T # [Entry] #public:
# [root] | Subtree # deny: r, c # Userpassword # public:
# [root] | Subtree # deny: r, C # rootpw # public:
# [root] | Subtree # deny: r, c # rootuser # public:
# [root] | Subtree # grant: r # userpassword # this:
# [root] | Subtree # Grant: W, O # Userpassword, Title, Description, Postaladdress, TelephonEnumber # this: # cn = schema | Entry # grant: r, s # [all] #public:
# cn = schema | Entry # Grant: B, T # [Entry] #public:
#
# Alternative Configuration - User CAN See Own Information and Update Subset Of
# attributes. no Other access is allowed.
#
# [root] | Subtree # Grant: s, r, b, t # [all] #this:
# [root] | Subtree # Grant: W, O # Userpassword, Title, Description, Postaladdress, Telephonenumber # this:
The following file is the acls.prop I modified, I give all the permissions to all users, using the file I modified, all users can add an entry or attribute, and of course, the sub-entry and attributes.
# ACLs -.. For more info on ACL syntax, refer to the WebLogic Server System Administration # Guide # # The default configuration is an empty file (nothing uncommented) This denies # access to everyone except the Admin DN Users may be able to bind ., but can # not read or modify entries in the LDAP server # # If you wish to enable additional access, choose one of the following configurations, # and uncomment the acl syntax by removing the '#' # # 7.0 Configuration - allows read Access to Everyone and Write Access To Own User Info # [root] | Entry # grant: s, r, o, w, c, m # [all] #public
[root] | Subtree # Grant: s, r, o, w, c, m # [all] #public:
[root] | Subtree # Grant: a, d, e, i, n, b, t # [entry] #public:
# [root] | Subtree # deny: r, w, o, c # Userpassword # public: # [root] | Subtree # deny: r, w, o, c # rootpw # public: # [root] | Subtree # deny : R, W, O, C # rootuser # public: # [root] | Subtree # Grant: r, w, o # Userpassword # this: # [root] | Subtree # Grant: W, O # Userpassword, Title, Description , Postaralddress, Telephonenumber # this: cn = schema | Entry # Grant: s, r, o, w, c, m # [all] #public:
CN = Schema | Entry # grant: a, d, e, i, n, b, t # [entry] #public:
