ops4j / org.ops4j.pax.web

OSGi R7 Http Service, Whiteboard and Web Applications (OSGi CMPN Release chapters 102, 140 and 128) implementation using Jetty 9, Tomcat 9 or Undertow 2.
https://ops4j1.jira.com/wiki/display/paxweb/Pax+Web
Other
146 stars 184 forks source link

A method to (re)configure existing contexts (for other bundles) using Configuration Admin [PAXWEB-1167] #1453

Closed ops4j-issues closed 6 years ago

ops4j-issues commented 6 years ago

Grzegorz Grzybek created PAXWEB-1167

The background of this issue is:

Keycloak project provides a tricky way to change this situation - by re-registering CXF servlet in http Service scoped for different (Keycloak's) bundle after registering login configuration (org.ops4j.pax.web.service.WebContainer#registerLoginConfig()) and adding security constraints (org.ops4j.pax.web.service.WebContainer#registerConstraintMapping). However, when org.apache.cxf.osgi PID changes, the Keycloak's re-registration is broken, because CXF registers another /cxf servlet in its own http service (risking duplicate alias mapping).

My idea is:

Here's example of PID:

# for which bundle do we want to acquire bundle-scoped org.ops4j.pax.web.service.WebContainer service?
bundle.symbolicName = org.apache.cxf.cxf-rt-transports-http

# what's the ID of org.osgi.service.http.HttpContext we want to get from
# org.ops4j.pax.web.service.WebContainer.createDefaultHttpContext(String contextId)?
context.id = default

# WEB-INF/web.xml's:
# <context-param>
#     <param-name>keycloak.config.resolver</param-name>
#     <param-value>org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver</param-value>
# </context-param>
# PAX-WEB's org.ops4j.pax.web.service.internal.HttpServiceStarted.setContextParam()
context.param.keycloak.config.resolver = org.keycloak.adapters.osgi.PathBasedKeycloakConfigResolver
context.param.param2 = value2
context.param.param3 = value3
# ...

# WEB-INF/web.xml's:
# <login-config>
#     <auth-method>KEYCLOAK</auth-method>
#     <realm-name>_does_not_matter</realm-name>
#     <form-login-config>
#         <form-login-page>/login</form-login-page>
#         <form-error-page>/logout</form-error-page>
#     </form-login-config>
# </login-config>
# PAX-WEB's org.ops4j.pax.web.service.WebContainer.registerLoginConfig()
login.config.authMethod = KEYCLOAK
login.config.realmName = _does_not_matter

# WEB-INF/web.xml's:
# <security-constraint>
#     <web-resource-collection>
#         <web-resource-name>secured</web-resource-name>
#         <url-pattern>/info</url-pattern>
#         <http-method>GET</http-method>
#     </web-resource-collection>
#     <auth-constraint>
#         <role-name>admin</role-name>
#     </auth-constraint>
# </security-constraint>
# <security-constraint>
# ...
# </security-constraint>
# ...
#
# <security-role>
#     <role-name>admin</role-name>
# </security-role>
# <security-role>
# ...
# </security-role>
# ...
# PAX-WEB's org.ops4j.pax.web.service.WebContainer.registerConstraintMapping()
security.constraint1.url = /cxf
security.constraint1.method = GET
security.constraint1.roles = admin, superuser, ...
security.constraint2.url = /other
security.constraint2.roles = admin
# ...

Having such facility inside pax-web-runtime gives me access to ServerController instance, so I can for example stop the context before adding context params / login configuration. Also some of the methods of should stop throwing IllegalStateException if the context has some already registered servlets. Instead the context should simply be restarted (just like its done currently if one simply registers two servlets in a row using HttpService).


Fixed in: 8.0.0, 7.2.0 Votes: 0, Watches: 1

ops4j-issues commented 6 years ago

Grzegorz Grzybek commented

Fixed here in https://github.com/ops4j/org.ops4j.pax.web/commits/pax-web-7.2.x branch.
Fixed here in https://github.com/ops4j/org.ops4j.pax.web/commits/master branch.

The documentation is available here: https://ops4j1.jira.com/wiki/spaces/paxweb/pages/354025473/HTTP+Context+processing