<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Liam,<br>
<br>
If it is mostly REST based services you want to work with, perhaps
APIs this might be a match: <a class="moz-txt-link-freetext" href="https://github.com/OpenConextApps/apis">https://github.com/OpenConextApps/apis</a><br>
"The apis (APIs Secure) project offers an OAuth 2.0 Authorization
Server that can be used to kickstart your API authentication. In
essence it enables you to focus on your actual resource endpoints
and use the out-of-the-box authorization server to authenticate
resource owners and subsequently validate the access tokens that
were granted to the Client applications."<br>
<br>
For authN it supports (amoung others) SAML2 based scenarios out of
the box.<br>
<br>
Cheers,<br>
Niels<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/23/2013 10:15 PM, Liam Hoekenga
wrote:<br>
</div>
<blockquote
cite="mid:CAH4ZtKQN5apP0ATutaVZ0ugMNGCiAx-xuNAeDMt1-xGF59MJLw@mail.gmail.com"
type="cite">We're looking to deploy WSO2's (web service) API
manager (<a moz-do-not-send="true"
href="http://wso2.com/products/api-manager/">http://wso2.com/products/api-manager/</a>).
We'd like to protect access to the web services using our
existing web auth infrastructure. The "easy" thing to do would be
to replace everything (e.g. shibboleth, our local web SSO, etc)
with the WSO2 versions of things. We don't want to do that.
<div>
<br>
<div>I'm being brought into this as the IAM guy.</div>
<div><br>
</div>
<div>The web services accessible via WSO2 need to be passed an
application authorization token and secret. In it's most
secured form, we also should pass it a user token and secret.
Normally tokens are generated by the wso2 token service. </div>
<div><br>
</div>
<div>The shib idp has to obtain / generate the token, then
passes it down the line as attribute data…. and then the web
application / web service ends up passing the token back into
wso2 to authorize the access. we'll need to figure out what
we can pass that can then be later validated. <br>
<div>
<p class="p1">The IdP could contact WSO2's token service,
and pass the token it generates on as to the service
provider as an attribute. The application hosted on the
service provider would then use the token (in the
attribute) back into WSO2 to authorize access to the web
services.</p>
<p class="p1">We could also use something already generated
by the IdP as the access token (the session token?), but
it would need to be something that WSO2 could validate
independently. I'm not sure that WSO2 could do anything
useful with session token, or if we could some how forward
on the SAML assertion that the IdP provided to the SP
during authentication.</p>
<p class="p1">I've done a few searches in the mailing list
archive and saw the suggestion that shib was never
intended to protect web APIs. We really don't want people
standing up additional authentication gateways as web
services and web and mobile apps are deployed.</p>
<p class="p1">Any suggestions would be most welcome.</p>
<p class="p1">thanks<br>
Liam</p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
To unsubscribe from this list send an email to <a class="moz-txt-link-abbreviated" href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></pre>
</blockquote>
<br>
</body>
</html>