-
Notifications
You must be signed in to change notification settings - Fork 33
How to configure Tyk Identity Broker
Tyk Identity Broker is configured through two files: The configuration file (tib.conf) and the profiles file (profiles.json). TIB can also be managed via the REST API (detailed below) for automated configurations.
{
"Secret": "test-secret",
"HttpServerOptions": {
"UseSSL": true,
"CertFile": "./certs/server.pem",
"KeyFile": "./certs/server.key"
},
"BackEnd": {
"Name": "in_memory",
"IdentityBackendSettings": {
"Hosts" : {
"localhost": "6379"
},
"Password": "",
"Database": 0,
"EnableCluster": false,
"MaxIdle": 1000,
"MaxActive": 2000
}
},
"TykAPISettings": {
"GatewayConfig": {
"Endpoint": "http://{GATEWAY-DOMAIN}",
"Port": "80",
"AdminSecret": "352d20ee67be67f6340b4c0605b044b7"
},
"DashboardConfig": {
"Endpoint": "http://{DASHBOARD-DOMAIN}",
"Port": "3000",
"AdminSecret": "12345"
}
}
}
The various configuration options are outlined below:
The REST API secret to configure the TIB broker remotely.
Set this to true to turn on SSL for the server, this is highly recommended.
The path to the certificate file for this server, required for SSL
The path to the key file for this server, required for SSL
TIB is quite modular and different back-ends can be generated quite easily, out of the Box, TIB will store profile configurations in memory, which does not require any new configuration.
For Identity Handlers that provide token-based access, it is possible to enforce a "One token per provider, per user" policy, which keeps a cache of tokens assigned to identities in Redis, this is so that the broker can be scaled and share the cache across instances.
Since profiles are unlikely to change often, profiles are kept in-memory, but can be added, removed and modified using an API for automated setups if required.
Add your redis hosts here as a map of hostname:port. Since TIB uses the same cluster driver as Tyk, it is possible to have TIB interact with your existing redis cluster if you enable it.
The password for your Redis DB (recommended)
If you are using multiple databases (not supported in Redis cluster), let TIB know which DB to use for Identity caching
If you are using Redis cluster, enable it here to enable the slots mode
Max idle connections to redis
Max active redis connections
This section enables you to configure the API credentials for the various Tyk Components TIB is interacting with.
The Hostname of the Tyk Gateway (this is for token generation purposes)
The Port to use on the Tyk Gateway host
The API secret for the Tyk Gateway REST API
The hostname of your Dashboard (Advanced API)
The port of your Advanced API
The high-level secret for the Advanced API. This is required because of the SSO-nature of some of the actions provided by TIB, it requires the capability to access a special SSO endpoint in the Advanced API to create one-time tokens for access.
The Profiles configuration file outlines which identity providers to match to which handlers and what actions to perform. The entries in this file encapsulate the activity for a single endpoint based on the ID and provider name.
The file is JSON object which is essentially a list of objects:
[{
"ActionType": "GenerateOrLoginUserProfile",
"ID": "1",
"IdentityHandlerConfig": {},
"OrgID": "53ac07777cbb8c2d53000002",
"ProviderConfig": {
"CallbackBaseURL": "http://tib.domain.com:3010",
"FailureRedirect": "http://tib.domain.com:3000/?fail=true",
"UseProviders": [{
"Key": "GOOGLE-OAUTH-TOKEN",
"Name": "gplus",
"Secret": "GOOGLE OAUTH SECRET"
}]
},
"ProviderConstraints": {
"Domain": "tyk.io",
"Group": ""
},
"ProviderName": "SocialProvider",
"ReturnURL": "http://tyk-dashboard.domain.com:3000/tap",
"Type": "redirect"
}, {
"ActionType": "GenerateOAuthTokenForClient",
"ID": "2",
"IdentityHandlerConfig": {
"DashboardCredential": "ADVANCED-API-USER-API-TOKEN",
"DisableOneTokenPerAPI": false,
"OAuth": {
"APIListenPath": "oauth-1",
"BaseAPIID": "API-To-GRANT-ACCESS-TO",
"ClientId": "TYK-OAUTH-CLIENT-ID",
"RedirectURI": "http://your-app-domain.com/target-for-fragment",
"ResponseType": "token",
"Secret": "TYK-OAUTH-CLIENT-SECRET"
}
},
"MatchedPolicyID": "POLICY-TO-ATTACH-TO-KEY",
"OrgID": "53ac07777cbb8c2d53000002",
"ProviderConfig": {
"FailureRedirect": "http://yourdomain.com/failure-url",
"LDAPAttributes": [],
"LDAPBaseDN": "cn=dashboard,ou=Group,dc=ldap,dc=tyk-test,dc=com",
"LDAPEmailAttribute": "mail",
"LDAPFilter": "((objectCategory=person)(objectClass=user)(cn=*USERNAME*))",
"LDAPPort": "389",
"LDAPServer": "localhost",
"LDAPUserDN": "cn=*USERNAME*,cn=dashboard,ou=Group,dc=ldap,dc=tyk-test,dc=com"
},
"ProviderName": "ADProvider",
"ReturnURL": "",
"UserGroupSeparator": ","
"Type": "passthrough"
}]
Each item in a policy list dictates how that component will behave with the underlying services it is trying to talk to. In the above two examples, we have a social provider, that will allow Dashboard access to Google plus users that are part of the "tyk.io" domain, in the case that you don't want a restriction based on the domain but only allow SSO access for existent dashboard users then you can set "SSOOnlyForRegisteredUsers": true . In the second example, we are generating an OAuth token for users that are validated via an LDAP server.
When a User is assigned to multiple Groups, the IDP will report these in a list - however different providers use different characters to separate the members of a list (e.g. blank space, comma). From TIB v1.3.1, the UserGroupSeparator config has been added to allow you to optionally configure which separation character TIB should use to split up the list of Groups. The default value is blank space, but you can set any character as required.
In the following sections we outline multiple configurations you can use for Identity Provision and Handling