There is a boolean called "allowCustomContent" that you can set on the AbstractOperation:
https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/operation/AbstractOperation.java#L107 Up to now it only supported DOM Elements. I've updated the code to allow JAXBElements as well. So if you grab the latest SNAPSHOT code for 3.2 or 3.1, and set that boolean, you will have access to the custom content in this class: https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/request/TokenRequirements.java#L48 For backwards compatibility reasons, in 3.1.x there will be two lists, one containing the custom DOM Elements parsed, and the other the custom JAXB Elements. Then you need to write a TokenProvider to understand the requested TokenType, which is not supported by default in CXF. Colm. On Tue, Aug 1, 2017 at 3:51 PM, NicholaiX <[email protected]> wrote: > At this point, I just need access to the BST inside the RST and forward it > to > a certificate issuer so it can issue me a certificate. I also need access > to > the AdditionalContext inside the RST (My request to the issuer needs to > contain both items) > > I haven't written the code yet since I didn't get past the BST hurdle, so > I > don't know how the implementation will go, I am open to any approach. I > don't see why it couldn't be a custom tokenprovider, assuming I can hand > off > both the BST and the additonalcontext. But since the BST and the > additionalcontext inside the RST are peers not parent/child, would that > work? > > > > > > > > > > > > -- > View this message in context: http://cxf.547215.n5.nabble. > com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected- > tp5782018p5782271.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
