protecting web services w/ shib
Liam Hoekenga
liamr at umich.edu
Tue Apr 23 16:15:11 EDT 2013
We're looking to deploy WSO2's (web service) API manager (
http://wso2.com/products/api-manager/). 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.
I'm being brought into this as the IAM guy.
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.
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.
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.
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.
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.
Any suggestions would be most welcome.
thanks
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130423/e0584127/attachment.html
More information about the users
mailing list