Scribing Template -Tues., Nov 12, 2013 at 4:15pm - Santa Clara
TOPIC: SOA Smelly / Federated RESTful
CONVENER: Bert
SCRIBE: David Langenberg
# of ATTENDEES: 11
MAIN ISSUES DISCUSSED:
web-services have many ways of doing AuthN, but every SOA and message-bus have not leveraged the various ways of doing AuthN. What are folks experiences?
What are folks using? National Student Clearinghouse has restful services, using JSON and annotations
it's hard to trust student projects with enterprise data and justify building infrastructure to support such projects? How can we standardize & build HA API without writing lots of code?
UIOWA has an identity warehouse. If app devs want to get some data, they'll create a SQL view for them. Presently now building common web API. Student side does something similar.
Challenge is being sure that the user doing the querying for data is authorized to view that particular data. Is the student using the app only seeing their own student data? UMA is recommended solution.
GLUU is writing a UMA plugin for web-servers to protect access to web-services. Use OpenIDConnect for the AuthN & UMA for the AuthZ
We want good web-services, but common documentation / troubleshooting / etc, and wide variety of folks consuming the services, but also want a common method for AuthN
There is no one true way. What you're protecting & why you're protecting it varies depending on the data.
There are different profiles -- user gets data @ keyboard, machine gets data from machine, etc
URL Authentication is course-grained. In enterprise space it's very common to do that.
Apogee & Layer 7 provide API gateway/proxy and have ways of providing AuthN/AuthZ.
FederatedID / REST -- focus is user @ keyboard
There is no silver-bullet.
Writing the policy for the access to the service is the interesting question. Generally how it's done is for the website to implement the policy at it's end.
ACTIVITIES GOING FORWARD / NEXT STEPS:
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org
You have to choose your poison. The information available to the application to make the AuthZ decision depends on the application's specific needs