1 / 42

Advanced Solr Cluster Security: Authentication and Authorization Framework

Improve user experience with Solr by enhancing security through authentication and authorization plugins. Learn about JWT basics, bundled security plugins, and Solr security prerequisites.

ladonnaf
Download Presentation

Advanced Solr Cluster Security: Authentication and Authorization Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Not-So-basic Auth Securing your Solr cluster Jason Gerlowski Solr Integration Engineer, Lucidworks Inc @jeg90 #Activate19 #ActivateSearch

  2. Who am I? “Improving the experience users have when picking up Solr for the first time … by adding to SolrJ, the bin/solr scripts, and the documentation” • Jason Gerlowski Email: gerlowskija@apache.org Twitter: @jeg90

  3. What’s “Off the Table”? • “Why” • Third Party Security Tie-ins, External Plugins (Apache Ranger, Apache Sentry) • Writing your own Security Plugin/Working with Plugins in Solr • Kerberos • SSL Configuration • Secure ZK Configuration

  4. Agenda • Authentication and Authorization • Framework details • Plugin Options • Prerequisites • JWT Authentication Plugin • JWT Process and Format • Plugin Configuration • Rule-Based Authorization Plugin • Basic Concepts • Plugin Configuration • Common Mistakes and Misunderstandings

  5. Authentication and Authorization

  6. Security Plugin Framework • Supports plugins for authentication, authorization, and audit-logging plugins • Third-party plugins supported. • Simple well-documented API • 4BUNDLED AUTHC PLUGINS • 1BUNDLED AUTHZ PLUGIN • 2AUDIT-LOGGING PLUGINS

  7. { "authentication":{ "class":"solr.BasicAuthPlugin", "blockUnknown": true, "credentials": {"solr-user":<encoded-creds>", "solr-admin":<encoded-creds>",} }, "authorization":{ "class":"solr.RuleBasedAuthorizationPlugin", "permissions":[ {"name":"security-edit", "role":"admin"}, {"name":"security-read", "role":"admin"} ], "user-role":{ "solr-user":"user", "solr-admin":"admin" } } }

  8. Bundled Security Plugins Authorization • Rule-Based Authorization Authentication • Kerberos • Hadoop Authentication • Basic Authentication • JWT Audit Logging • Solr Log • Multi-Destination

  9. Bundled Security Plugins Authorization • Rule-Based Authorization Authentication • Kerberos • Hadoop Authentication • Basic Authentication • JWT Audit Logging • Solr Log • Multi-Destination

  10. Solr Security Framework Prerequisites • SSL configured? • ZK security enabled? • ZK SSL enabled? ( where available, starting Solr 8.2+) • Disk encryption?

  11. JWT Authentication Plugin

  12. JWT Authentication Token-based model Identity Provider <JWT> User Solr

  13. JWT Authentication Token-based model Identity Provider <JWT> User Solr

  14. JWT Basics What is a JWT anyways? Header{ "alg":"HS256", "typ":"JWT" } Payload { "iat":"14227796", "exp":"14228896", "sub":"username", "iss":"foo.com" ... } Signature <binary>

  15. JWT Basics What is a JWT anyways? base64UrlEncode(header) + ‘.’ + base64UrlEncode(payload) + ‘.’ + base64UrlEncode(signature) eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI curl -k -H “Authorization: Bearer eyJhb..<snip>..SpyHI” “http://host:8983/solr/coll1/select”

  16. Solr JWT Configuration JWK Key {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "jwk": { "kty": "RSA", "alg": "RS256", "use": "sig", "kid": "test", "e": "AQAB", "n": "jeyrv..<snip>..MUfqQ" } } }

  17. Solr JWT Configuration (cont’d) JWK URL Configuration {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "jwkUrl": "http://my.key.server.com" } }

  18. Solr JWT Configuration (cont’d) OpenID Connect Configuration {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "wellKnownUrl": "https://foo.openid.com/well-known/open-id-configuration" } }

  19. Solr JWT Configuration (cont’d) Other Configuration Options {"authentication": { "class": "solr.JWTAuthPlugin", "blockUnknown": true, "wellKnownUrl": "https://foo.openid.com/well-known/open-id-configuration", "scope": "solr:read solr:write solr:admin", "requireExp": true, "claimsMatch": { "foo": "A|B", "dept": "IT" }, "algWhitelist": [ "RS256", "RS384", "RS512" ], "jwkCacheDur": 1800 } }

  20. Rule Based Authorization Plugin

  21. Rule-Based Authorization Core Concepts Permissions - access rules; restrict access to specific “roles” Roles - user-defined grouping for users. Share permissions Users - principal verified by authentication plugin

  22. Rule-Based Authorization Permission Syntax: Predefined • security-read, security-edit, schema-read, schema-edit, config-read, config-edit, core-admin-read, core-admin-edit, collection-admin-read, collection-admin-edit, read, update, all {"name": "read", "role": "dev"}

  23. Rule-Based Authorization Permission Syntax: Custom { "name": "system-export", "collection": "*", "path": "/export", "role": "admin" }

  24. Rule-Based Authorization Security.json Example { "authorization": { "class": "solr.RuleBasedAuthorizationPlugin", "permissions": [ {"name": "foo-access", "collection": "foo", "role": "*"}, {"name": "all", "role": "admin"} ], "user-role": {"admin-user": "admin", "dev-user": "dev"} } }

  25. Permission Resolution Quirks

  26. Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": "dev"}, {"name": "read", "role": "admin"}

  27. Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": "dev"}, {"name": "read", "role": "admin"}

  28. Rule-Based Authorization Permission Resolution Issue #1 • One permission always controls the request (even if multiple technically “match”) GET /solr/collection1/select?q=*:*” {"name": "read", "role": ["dev", "admin"]}

  29. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom.

  30. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. Top - to - Bottom

  31. Rule-Based Authorization Permission Resolution Issue #2 Admin Request? • Check permissions specific to collection and path • Check permissions specific to collection (not path) • Check permissions specific to path (not collection) • Check permissions specific to neither path nor collection No Yes • Check permissions specific path • Check non-path-specific permissions More specific permissions considered first.

  32. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/admin/info

  33. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/admin/info (3)

  34. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/foo/select?q=*:*

  35. Rule-Based Authorization Permission Resolution Issue #2 • Permission ordering is unintuitive - NOT always top to bottom. • {"name": "read", "role": "dev"} • {"name": "foo-read", "collection": "foo", "role": "other", "path": "/select"} • {"name": "all", "role": "admin"} What order will the permissions be checked for the request: GET /solr/foo/select?q=*:* (2)

  36. Rule-Based Authorization Permission Resolution Issue #3 • Permission names matter! {"name": "read", "role": "dev", "method": "GET"}

  37. Rule-Based Authorization Permission Resolution Issue #3 • Predefined permission names are often misleading! Which endpoints does the “read” permission control? • - /solr/collection1/select?q=*:* • - /solr/admin/collections?action=CLUSTERSTATUS • - /solr/admin/collections?action=LIST • - /solr/collection1/export • - /solr/collection1/schema

  38. Rule-Based Authorization Permission Resolution Issue #3 • Predefined permission names are often misleading! Which endpoints does the “read” permission control? • - /solr/collection1/select?q=*:* • - /solr/admin/collections?action=CLUSTERSTATUS • - /solr/admin/collections?action=LIST • - /solr/collection1/export • - /solr/collection1/schema

  39. Rule-Based Authorization Putting it all together • {"name": "all-cols", "role": "A", "collection": "*", "path": "/select"}, • {"name": "custom-schema-read", "role": "A", "path": "/schema"}, • {"name": "read", "role": "B", "collection": "system"}, • {"name": "read-sys", "role": "C", "collection": "system", "params": {"fl": ["secret_field"]}}

  40. Rule-Based Authorization Common Traps • Only the first “matching” permission is considered for a request • Permissions are not (always) processed in the order they appear in security.json • Permission names matter! Override method, params, other attributes. • Predefined permission names are deceptive • Failing open: if no permissions “match”, request is allowed

  41. Rule-Based Authorization Troubleshooting and Tips • Order permissions: most to least specific • End permission list with catch-all permission to prevent “failing open” • Prefix all custom rules to avoid collisions with “predefined” permissions • Raise logging-level for org.apache.solr.security.RuleBasedAuthorizationPlugin (8.3+) • Automate testing of authorization changes

  42. Thank You! http://home.apache.org/~gerlowskija/authcz.pptx

More Related