Kusanidi proksi kwa upakuaji wa metadata za SAML katika Spring Security ya zamani
Sanidi mteja wa HTTP anayeingizwa kwenye HTTPMetadataProvider ya zamani ya Spring Security SAML kwa upakuaji wa metadata upande wa seva.
Programu ya zamani ya Spring Security SAML inaweza kupata metadata za mtoa utambulisho kutoka kwa mchakato wa seva kwa kutumia HTTPMetadataProvider. Upakuaji huo wa nje hutumia mteja wa HTTP aliyopewa mtoa metadata.
Kwa programu inayotumia mtindo wa usanidi wa Spring Security SAML 1.0.x/OpenSAML 2, sanidi Apache Commons HttpClient yake kabla ya kuingizwa:
org.apache.commons.httpclient.HttpClient metadataHttpClient =
new org.apache.commons.httpclient.HttpClient();
metadataHttpClient.getHostConfiguration()
.setProxy("proxy.example", 8080);Pitisha kitu hicho kilichosanidiwa kama hoja ya kijenzi cha mteja wa HTTP wa org.opensaml.saml2.metadata.provider.HTTPMetadataProvider, pamoja na kipima muda na URL ya metadata iliyopo. Katika usanidi wa XML, bean ya mteja inayorejelewa lazima iwe nakala hii iliyosanidiwa.
Hifadhi dimbwi la vichanganuzi lililopo la mtoa, usanidi wa kuonyesha upya na msimamizi wa metadata anayozunguka. Kubadilisha njia hakubadilishi majukumu hayo.
URL ya metadata inabaki kuwa URL ya mtoa utambulisho. Mwenyeji wa proksi ni wa mteja wa HTTP. Kwa URL ya metadata iliyoidhinishwa na inayofikiwa na umma, mgombea wa HTTP kutoka orodha ya proksi za HTTP anaweza kujaza mwenyeji na lango la mteja huyo wakati waamuzi wa umma wanaruhusiwa na hakuna vitambulisho vya proksi vinavyohifadhiwa. Hii ni njia ya upataji upande wa seva: uelekezaji wa kivinjari uliofanikiwa kwa mtoa utambulisho hauonyeshi kuwa seva ya programu inaweza kupakua au kuonyesha upya metadata kupitia vikwazo vyake vya mtandao.
Tumia usanidi huu kwa madaraja ya zamani yaliyotajwa hapa pekee. Msaada wa kisasa wa Spring Security saml2 hutumia API nyingine, na bean iliyoandikwa kwa kiendelezi cha zamani haiwezi kubadilishana na usanidi wake wa sasa wa metadata.