SAML SP

[dominic_varillo]

Hi,

I am receiving the error message: "The getSpMetadataForAdmin method was not found." when I click on an existing SP to edit it. I also get the message when I add a new SP. It adds the SP but then throws the error when try to display it. Adding and editing an IDP is fine. I am on CF 2021 Standard. I upgraded to update 12 from 5 and changed the JVM to 11.0.26 and uninstalled and reinstalled the SAML package to try to fix this but I still get the error. It seems manually modifying the neo-saml.xml file does not work either without restarting CF, but that is still unclear. Has anyone else experienced this or know how I can fix it?

Thanks,

Dom

[Charlie Arehart]

Here are two things to try:

1.  Do what the technotes refer to as "clear the felix-cache", by which they mean stop CF, and delete the folder in cfusion/bin called felix-cache (deleeting it and all subfolders, with no need to "save them" for any reason). On restart, CF will rebuild them. Even though it's not a known issue tha tthis would help with your problem, it has helped with many (as indicated in various update technotes over the past few). This folder holds files related to CF's "package management" feature, and it seems that sometimes something gets out of synch, which is why Adobe recommends this "solution".
   
   
2.  If that does not work, then stop CF again and delete the cfusion/wwwroot/WEB-INF/cfclasses folder.  This folder instead holds the java classes compiled from your CFML. Again, sometimes things get out of synch. For this folder, there is an argument for renaming it rather than deleting it (while CF is stopped), as there may be some value in the info tracked about these files.  It shoudn't be "huge" in size. And if you wanted to, you could do both after stopping CF for step 1. I only proposed them separately to help you (and us) know "which"solved it, if either does, for the benefit of future readers.

Let us know if it helps or not. If not, I have another suggestion but I'll hold off to hear what you report.

[dominic_varillo]

Thanks for the reply Charlie. Unfortunately, I did each of these separately and each time I received the same error message when I try to edit the one test SP i have created. Any other suggestions would be appreciated.

Dom

[Scott_Stewart3951]

I'm seeing a similar issue, when updating Service Provider configuration data. I hit update and the form crashes. I can shut down the CFApplication service and reconstruct the neo-saml.xml file and then restart, but this is clumsy at best.

I've opened a bug tracker: https://tracker.adobe.com/#/view/CF-4226362

[BKBK]

Hi @Scott_Stewart3951 ,

I have voted for the SAML issue to be resolved. However, I do not believe it is related to the STAX warning in coldfusion-out.log.

See my STAX post in this previous thread: https://community.adobe.com/t5/coldfusion-discussions/what-is-unable-to-determine-dialect-of-the-sta... 

[Charlie Arehart · Accepted solution]

Folks, there are two different issues being discussed here: while both relate to editing sp configs, Dom's is the error about " getSpMetadataForAdmin method was not found" (happening on his update 12) while Scott's is the "keystorepath" error as he mentioned on his tracker ticket (where he also indicated he is on update 18).

1) So first, about Dom's error, I can report that that IS indeed SPECIFICALLY because he is on update 12. I finally had time to set things up and test, and the error happened on 12 but NOT on 13 (or later. FWIW, it also didn't happen on update 2, which is where a fresh install started for me tonight.) So Dom (and anyone else with this first error), consider going to update 13 to solve that. Do beware that update 13 (from March 2024) had other significant changes, especially the one about searchimplicitscopes. See the update 13 technote for more on that, and/or an elaborated post I did at the time with still more.

2) Second, as for Scott's error, I will say that I have NOT gotten the eror, regardless of what update I'm on. That's odd that it's happening for you. I concur with BKBK pointing out that the Stax error (you refer to in the tracker ticket) is something EVERYONE sees. You can ignore it, and therefore it's NOT the issue (but I appreciate why you wondered if it may be).

I'll propose to you here what I did above to Dom in my FIRST reply (and we can add it to the ticket if it works for you): stop CF, delete the felix-cache folder (in cfusion/bin) then start CF. No need to "save" that folder: the restart of CF will replace the folder for you. And if that alone doesn't work, consider next stopping CF and deleting (or renaming) the cfusion/wwwroot/WEB-INF/cfclasses folder. Then start CF and again it will be created for you.

Both those steps simply involve clearing out previously compiled java that may have been implemented in prior updates for you. Again, I don't get the error you do, so it seems definitely something environmental on your end. And since your edit of the neo-saml.xml is not preserved it COULD be related to that issue.

Hope these help here.

[Scott_Stewart3951]

I cleared the felix cache, cfclasses, java cache.. even cleared the browser cache. Same result. I did however observe that it seems to be centered around the field for the keystore password, I unchecked sign logout response, saved and the form rendered, however with the data for the fields below missing . When I edited the file again I replaced the missing data, saved and then the form crashed with the same missing keystorepath error

Its the same fields that are deleted from neo-saml.xml everytime. 
signKeystorePath
signKeystorePassword
signKeyStoreAlias

[Charlie Arehart]

Would you be willing to share privately the xml file? I'd compare it to a working one. Perhaps there's something amiss, some subtle difference. My email is charlie@carehart.org. 

[Scott_Stewart3951]

Charlie, 

Unfortunately, I can't because its a Federal system, no one is taking any chances right now. 

[Charlie Arehart]

You could remove every value (not any xml, just info between quotes, or names, etc.) . There would be then nothing unsafe or private about it. 

[Scott_Stewart3951]

We have in house XML validator tools. I did run the working and nom working neo-saml.xml and working files against those and they did both vakidate

[Charlie Arehart]

If you mean a generic xml validation tool, that's not at all where I was headed (also, cf does such generic validation in loading its xml files). But I appreciate you're just trying to facilitate things. 

I'm referring instead to the nature of the xml elements, as far as how cf loads and processes that. I've certainly seen problems over the years where a neo xml file is "valid" generically but cf would not process it.

As an example (I'm not saying it's your case), some folks will bring one or all neo xml files from one CF instance to another. Sometimes that's fine. Often it's not, for any of many reasons. Again, I'm not saying you did that. I'm simply proposing that your validation, if generic, is insufficient.

And I understand you'll just want the bug fixed. But Adobe needs to be able to recreate it, to fix it. 

Again, I took the time to implement cf2021 update 18, as you indicated, and I could add and edit sp's. Further,. I did it first filling in only the required fields, then all fields, and several permutations in between. I'm just trying to help. 

Perhaps a concern you have is that you have dozens of sp's you'd need to redact. Understandable. If you reduce it to one--for this testing, and it fails this way (after restarting cf), then at least you need only redact the values for that one. 

[Scott_Stewart3951]

Charlie, 
I get it and I appreciate the help. I'm going to (try) to attach a zip file with two heavily redacted verisons of neo-saml.xml. There's no identifying information its basically the XML fields with no data. 

[Scott_Stewart3951]

So, I'll email them to you as the upload feature is complaining about formats not matching, maybe the wddx headers?

[dominic_varillo]

I can confirm that going past update 12 did in fact fix this issue fo me. Thanks

[Charlie Arehart]

Great to hear, Dom. And thanks for marking the answer. Now we'll attend to Scott's different issue. And one could argue it's OK for both to be discussed here, given the generic nature of the title you'd originally chosen. 🙂