LDAP / HTTP look up
To connect the user with the Buypass Systems, the user’s mobile phone number must be registered in LDAP or another user catalog that is available through HTTP. To make the connection stronger it is also possible to register the App-ID. Note that the use of App-ID is configured for each LDAP / HTTP configuration.
It is the customer sites own responsibility enabling BP Code for their users in their authentication solutions.
Prioritization
Queries in the LDAP / HTTP directories are performed in the order they are shown in the list. By using the up- and down buttons the order can be changed. Queries are first done in the cached user catalogue. If the user is not found in the cache, the queries are performed in the defined order. If changes are done to the preferred query order, the cache must be cleared.
Clear the cache
The button “Clear cache” will empty the cache for all users. It is also possible to clear the cache for individual users in the Users menu.
LDAP
The information here is used to create an LDAP connection, and to know which attributes are used to create the link between the user and Buypass Code. To edit the LDAP configuration press the “Edit” button under the detailed view of the LDAP connection. To edit a LDAP path press the chosen path to be edited.
The fields in the LDAP catalogue that are used for storing the mobile phone number, App-ID and username is decided by the customer. These fields must be configured in the Buypass Code Manager, so that the Service Connector can look up the user when authentication is performed.
Configuration
URL: URL that is used to find the LDAP server. This must be a valid URI, in the form of ldap://machine.domain.no[port]. The port number is only required if it is different from the standard port.
E.g.: ldap://ldap.domene.no:10001
Username: Username of the service account that in combination with a password are used to authenticate against the AD/LDAP server for querying the user information. The user account should from a security perspective be a read-only user.
E.g.: BPCodereadonlyuser
Password: The password, in combination with the username, is used to authenticate against the AD/LDAP server.
E.g.: verysecretpassword117788
Phone.no. attribute: Defines which attribute in the LDAP catalogue is used to store the telephone number used by Buypass Code. In combination with the App-ID attribute this is used to decide who is allowed to log on with Buypass Code. The default setting for this is the attribute "telephoneNumber". For searching in additional attributes these are separated with ";" and will be prioritized in the order they are defined. This means that if the configuration is the following: ”telephoneNumber;pager”, the number in the telephoneNumber attribute be used. If telephoneNumber is empty, the number found in pager will be used. If the number that is found is missing Country Code, the standard Country Code for the Customer Site will be used
E.g.: telephoneNumber;pager
App-ID attribute: Defines which attribute in AD/LDAP catalogue that is used to store App-ID for use in Buypass Code. In combination with telephoneNumber attribute this is used to find which users are allowed logging on with Buypass Code. By defining the App-ID attribute the requirement for having stored the correct App-ID in AD/LDAP is activatet. This means that if a user does not have the App-ID stored in the LDAP catalogue the user is not allowed to log on.
E.g.: driverLicenseNo
LDAP path configuration
The information here defines how to find the users in a given LDAP catalogue.
Priority: The paths will be used in the order they have in the list.
LDAP path: The path is used to find valid users in the AD/LDAP that Buypass Code will use to match mobile phone number and/or AppID against.
The paths must be in the form of: basedn[path-to OU-containing-the-user],filter[attributes-to-validate-users-against]. If the string within the basedn brackets ends with a " * ", recursive searching will be performed. The Filter-string must contain "#USER" which is used to match the username against the defined attribute in AD/LDAP.
Example 1:
basedn[OU=Users,DC=domain,DC=net],filter[samAccountName=#USER#]
Defines that Buypass Code shall search for valid users in the OU «Users» in the Active Directory domain «domain.net», and then match the username against the attribute “samAccountName”
Example 2:
basedn[OU=Users,DC=domain,DC=net(*)],filter[samAccountName=#USER#]
Defines that Buypass Code shall search for valid users recursive in the OU Users inclusive all sub-OUs, in the domain “domain.net”, and then match the username against the attribute “samAccountName”.
Example 3:
basedn[CN=company],filter[userName=#USER#,vpnAllowed=true]
Defines that Buypass Code shall look for valid users in the basedn «company», and then match the username against the attribute “userName”, but only if the attribute “vpnAllowed” has the value “true”.
Example 4:
basedn[OU=OU_name,DC=example,DC=com(*)],filter[(&(samAccountName=#USER#)(memberof=CN=group_name,CN=Users,DC=example,DC=com))]
Query with "memberof" for allowing group managed access in Active Directory.
Secure communication with LDAP
The Service Connector can perform queries in the user catalogue with encrypted LDAP. This is done by creating a new LDAP configuration in Code Manager. An encrypted LDAP-connection is created by configuring the URL parameter to use the LDAPS protocol. (e.g. ldaps://myldap.hostname). If no port number is chosen the default port 636 is used. If the certificate on the LDAP server is not from a CA (Certificate Authority) approved by Java the certificate must be imported into the Java certificate storage.
Below is an example on how to import a certificate named ldaps-cert.cer.
Open a command prompt as administrator on the computer running the Service Connector.
Change current working directory:
cd \bps\jre\lib\security
Import the certificate with the following command:
\bps\jre\bin\keytool -importcert -trustcacerts -alias root -keystore cacerts -file ldaps-cert.cer Enter keystore password: changeit Trust this certificate? [no]: yes
HTTP
HTTP-requests for Buypass Code makes it possible for the customer sites to query users over HTTP instead of LDAP catalogue.
Request
Buypass sends a GET request to the defined URL with the parameter "user" which is the username of the user.
E.g.: https://www.yoursite.no/lookup?user=myusername
Response
Possible response scenarios:
HTTP status code | HTTP response body | Forklaring |
---|---|---|
200 | phone=XXXXXX&appid=YYYYYYYYYYY | If the user exists. "phone" and "appid" are examples and are specified for each configuration. |
404 | If the user is not found. | |
400 | If the input parameters are invalid. | |
500 | If there is an internal error. |
Configuration
URL: The URL used to find the HTTP server. Must be a valid URI, e.g. https://domene.no.
E.g. https://www.yoursite.no/lookup
Username: The username in combination with the password is used to authenticate against the HTTP server if basic autentication is used.
E.g.: BPCodereadonlyuser
Password: The password in combination with the username is used to authenticate against the HTTP server if basic autentication is used.
E.g.: verysecretpassword117788
Phone.no. attribute: Defines the response parameter used for returning the telephone number used by Buypass Code. If the number found is missing the country code, the standard country code for the merchant site is used.
E.g.: telephoneNumber
App-ID attribute: Defines which response parameter is used for returning the App-ID used by Buypass Code. In combination with Phone.no this is used to find which users have permission to log on. By definng the App-ID attribute the requirement for the App-ID is activated. This means that if the response for a user does not contain the App-ID the user is not allowed to log on.
E.g.: appId