[jira] [Created] (CXF-4544) Create a common SAML-based SecurityContext for both the JAX-RS and JAX-WS layers
Colm O hEigeartaigh created CXF-4544: Summary: Create a common SAML-based SecurityContext for both the JAX-RS and JAX-WS layers Key: CXF-4544 URL: https://issues.apache.org/jira/browse/CXF-4544 Project: CXF Issue Type: Improvement Components: JAX-RS Security, WS-* Components Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.7.0 This task is to create a common SAML-based SecurityContext for both the JAX-RS and JAX-WS layers. At the moment, the JAX-WS layer creates a LoginSecurityContext to return the principal + roles extracted from a SAML Assertion. However, it does not store the SAML Assertion itself. The JAX-RS layer has a custom SecurityContext implementation that stores the roles etc. This task will add a new SAMLSecurityContext class to the rt-core module, and so downstream code can access a SAMLSecurityContext independently of whether it came from the JAX-RS or JAX-WS layer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4544) Create a common SAML-based SecurityContext for both the JAX-RS and JAX-WS layers
[ https://issues.apache.org/jira/browse/CXF-4544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4544. -- Resolution: Fixed > Create a common SAML-based SecurityContext for both the JAX-RS and JAX-WS > layers > > > Key: CXF-4544 > URL: https://issues.apache.org/jira/browse/CXF-4544 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security, WS-* Components >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.7.0 > > > This task is to create a common SAML-based SecurityContext for both the > JAX-RS and JAX-WS layers. > At the moment, the JAX-WS layer creates a LoginSecurityContext to return the > principal + roles extracted from a SAML Assertion. However, it does not store > the SAML Assertion itself. The JAX-RS layer has a custom SecurityContext > implementation that stores the roles etc. > This task will add a new SAMLSecurityContext class to the rt-core module, and > so downstream code can access a SAMLSecurityContext independently of whether > it came from the JAX-RS or JAX-WS layer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4526) PolicyAnnotationListener throws NPE in jar
[
https://issues.apache.org/jira/browse/CXF-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470324#comment-13470324
]
Emil Bergner commented on CXF-4526:
---
Daniel, I can confirm that it's working now (at least with my setup). Many
thanks!
> PolicyAnnotationListener throws NPE in jar
> --
>
> Key: CXF-4526
> URL: https://issues.apache.org/jira/browse/CXF-4526
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.6.2
>Reporter: Emil Bergner
>Assignee: Daniel Kulp
>Priority: Minor
> Labels: bug, jar, maven, policy
> Fix For: 2.5.6, 2.6.3
>
>
> I've attached a security policy to my service using:
> @Policy(uri = "classpath:some-security-policy.xml", placement =
> Policy.Placement.DEFAULT)
> Everything works fine inside Eclipse. But an NPE is thrown in
> PolicyAnnotationListener on line 348 when I run the executable jar that I
> build with maven-shade-plugin:
> Exception in thread "main" javax.xml.ws.WebServiceException:
> java.lang.NullPointerException
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:357)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:246)
> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:525)
> at com.reverb.ison.ws.InteliSonServer.publish(InteliSonServer.java:21)
> at com.reverb.ison.ws.InteliSonServer.main(InteliSonServer.java:15)
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.ws.policy.PolicyAnnotationListener.addPolicy(PolicyAnnotationListener.java:348)
> at
> org.apache.cxf.ws.policy.PolicyAnnotationListener.addPolicy(PolicyAnnotationListener.java:328)
> at
> org.apache.cxf.ws.policy.PolicyAnnotationListener.addPolicies(PolicyAnnotationListener.java:249)
> at
> org.apache.cxf.ws.policy.PolicyAnnotationListener.addPolicies(PolicyAnnotationListener.java:165)
> at
> org.apache.cxf.ws.policy.PolicyAnnotationListener.handleEvent(PolicyAnnotationListener.java:77)
> at
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.sendEvent(AbstractServiceFactoryBean.java:72)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:200)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:159)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:442)
> at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:329)
> ... 4 more
> Looks like the issue is:
> cls.getResource("/").toString()
> which will return null when the class is inside a jar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4545) ut_sign + sign_enc samples broken in last releases
Colm O hEigeartaigh created CXF-4545: Summary: ut_sign + sign_enc samples broken in last releases Key: CXF-4545 URL: https://issues.apache.org/jira/browse/CXF-4545 Project: CXF Issue Type: Bug Affects Versions: 2.6.2, 2.5.5, 2.4.9 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.4.10, 2.5.6, 2.6.3 The ut_sign + sign_enc samples are broken in the last releases (2.4.9, 2.5.5 and 2.6.2). The reason is that the DefaultCryptoCoverageChecker has been added, and it throws an exception as the wsa:ReplyTo header has not been signed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4545) ut_sign + sign_enc samples broken in last releases
[ https://issues.apache.org/jira/browse/CXF-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-4545. -- Resolution: Fixed > ut_sign + sign_enc samples broken in last releases > -- > > Key: CXF-4545 > URL: https://issues.apache.org/jira/browse/CXF-4545 > Project: CXF > Issue Type: Bug >Affects Versions: 2.4.9, 2.5.5, 2.6.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.4.10, 2.5.6, 2.6.3 > > > The ut_sign + sign_enc samples are broken in the last releases (2.4.9, 2.5.5 > and 2.6.2). The reason is that the DefaultCryptoCoverageChecker has been > added, and it throws an exception as the wsa:ReplyTo header has not been > signed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4546) @XMLInstruction
Glen Mazza created CXF-4546:
---
Summary: @XMLInstruction
Key: CXF-4546
URL: https://issues.apache.org/jira/browse/CXF-4546
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.6.2
Reporter: Glen Mazza
Priority: Minor
org.apache.cxf.jaxrs.ext.xml.XMLInstruction doesn't seem to handle stray white
space particularly well:
@XMLInstruction("")
works fine (outputs as http://localhost:9998/foobar.xsl'?>), but:
@XMLInstruction("")
(w/stray space between ending apostrophe and ending ?)
outputs as:
http://localhost:9998/foobar.xsl''?>
(erroneous double apostrophe at the very end).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4546) @XMLInstruction
[
https://issues.apache.org/jira/browse/CXF-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470423#comment-13470423
]
Glen Mazza commented on CXF-4546:
-
Also consider providing an ability to suppress expansion of the href attribute,
i.e., not adding the http://xxx part.
> @XMLInstruction
> ---
>
> Key: CXF-4546
> URL: https://issues.apache.org/jira/browse/CXF-4546
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.6.2
>Reporter: Glen Mazza
>Priority: Minor
>
> org.apache.cxf.jaxrs.ext.xml.XMLInstruction doesn't seem to handle stray
> white space particularly well:
> @XMLInstruction("")
> works fine (outputs as href='http://localhost:9998/foobar.xsl'?>), but:
> @XMLInstruction("")
> (w/stray space between ending apostrophe and ending ?)
> outputs as:
> http://localhost:9998/foobar.xsl''?>
> (erroneous double apostrophe at the very end).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4543) Encode multi value claims as multi-value saml attribute
[ https://issues.apache.org/jira/browse/CXF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470468#comment-13470468 ] Daniel Kulp commented on CXF-4543: -- I just changed it from String to List and updated the various methods appropriately. Can you verify that that would be adequate? I really prefer the typed collection than a raw object. > Encode multi value claims as multi-value saml attribute > --- > > Key: CXF-4543 > URL: https://issues.apache.org/jira/browse/CXF-4543 > Project: CXF > Issue Type: Improvement > Components: Services >Affects Versions: 2.7.0 >Reporter: Oliver Wulff > > The current ClaimsAttributeStatementProvider supports encoding for string > type value of claims. It's up to the ClaimsHandler to implement multi-value > claim support and encoding. > As mentioned here: > http://cxf.547215.n5.nabble.com/SAML-2-0-attibutes-and-claims-naming-convention-td5712967.html > The type of the value in the class Claim has to be changed from String to > Object. The ClaimsAttributeStatementProvider can then be configured how to > encode multi value claims. Fediz already supports both since FEDIZ-22. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4543) Encode multi value claims as multi-value saml attribute
[ https://issues.apache.org/jira/browse/CXF-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470709#comment-13470709 ] Oliver Wulff commented on CXF-4543: --- I agree with you with respect to typed collection. A claim value can be a simple type or a list of simple types. The encoded xml element includes the xsi:type. Well, the spec also allows complex types: 1237 The element supplies the value of a specified SAML attribute. It is of the 1238 xs:anyType type, which allows any well-formed XML to appear as the content of the element. 1239 If the data content of an element is of an XML Schema simple type (such as 1240 xs:integer or xs:string), the datatype MAY be declared explicitly by means of an xsi:type declaration 1241 in the element. If the attribute value contains structured data, the necessary data 1242 elements MAY be defined in an extension schema. I thought the object type provides most flexibility. Initially, we would support basic types and list of basic types in the ClaimsAttributeStatementProvider. If anybody wants to support complex types in custom claimshandler he can do that but only with a more flexible type than List. WDYT? > Encode multi value claims as multi-value saml attribute > --- > > Key: CXF-4543 > URL: https://issues.apache.org/jira/browse/CXF-4543 > Project: CXF > Issue Type: Improvement > Components: Services >Affects Versions: 2.7.0 >Reporter: Oliver Wulff > > The current ClaimsAttributeStatementProvider supports encoding for string > type value of claims. It's up to the ClaimsHandler to implement multi-value > claim support and encoding. > As mentioned here: > http://cxf.547215.n5.nabble.com/SAML-2-0-attibutes-and-claims-naming-convention-td5712967.html > The type of the value in the class Claim has to be changed from String to > Object. The ClaimsAttributeStatementProvider can then be configured how to > encode multi value claims. Fediz already supports both since FEDIZ-22. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
