<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>WRT the IBM API Manager..</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_6254868491031486745:73v" class="gmail-m_6254868491031486745a3s gmail-m_6254868491031486745aXjCH gmail-m_6254868491031486745m1579bfef896e67ed">If you care about the content, then you better care about the content.  You can't care about part of the token(uniqname:token) and not the rest.<br></div></blockquote><div><br></div><div>The token validation web services needs to care about the content of the token.  Our thinking is that it would be better to implement a reusable standard (i.e. JWT) than create an arbitrary, single purpose token creator / validator.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_6254868491031486745:73v" class="gmail-m_6254868491031486745a3s gmail-m_6254868491031486745aXjCH gmail-m_6254868491031486745m1579bfef896e67ed">
If all you want is "IS IT YES?"  "YES"/"NO", that's the most degenerative case of not caring about the contents.  200 is yes, anything else is no.  Shim, proxy, direct, whatever.<br></div></blockquote></div><br>The only thing the API Manager is interested is a YES / NO answer.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Our current plan is to pursue a RapidConnect like JWT creation / validation service.</div><div class="gmail_extra">While we could script the creation of the token value, we'd rather not have multiple copies of the creation code, so we'd rather pull it from the web service.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Any suggestions on accessing a SAML protected web service via a scripted attribute in the Shib IDP?</div><div class="gmail_extra"><br></div><div class="gmail_extra">LIam</div></div>