<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 14/10/2015 14:57, Eric Wittmann wrote:<br>
<blockquote cite="mid:561E5F51.3080504@redhat.com" type="cite">That's
an imaginative use of apiman and it should work precisely as you
have described it. You are right that if you use applications,
then you must also have at least one plan. The API key is
necessary in this situation because the gateway will need to know
which application is calling the service (so that it can pick the
right set of policies to apply).
<br>
</blockquote>
Yes, I understand why that is necessary.<br>
This is because the service is being called directly through the
service owner's "path". e.g.<br>
<meta charset="utf-8">
/apiman-gateway/ServiceOwnerOrg/service/1.0<br>
<meta charset="utf-8">
Might it (in principle) be possible to access the service through
the the application owners "path" e.g <br>
/apiman-gateway/AppOwnerOrg/AppName/ServiceOwnerOrg/service/1.0 <br>
<br>
<blockquote cite="mid:561E5F51.3080504@redhat.com" type="cite">
<br>
Your only other solution would be a custom authentication policy,
which would obviously allow you to do whatever you wanted. In
that scenario, you will presumably still need to identify the
application/organization in some way. For example, each
application would need to identify itself via a custom http
header, or a query param, etc.
<br>
</blockquote>
Yes, that might work. A sort of delegating authenticator that
delegates to the appropriate realm based on a header param.<br>
But it would not allow each organisation to provide custom policies.
e.g. I have in mind that an individual organisation might want to
add user based rate limiting to prevent one of its users using all
the organisation's quota.<br>
<br>
Tim<br>
<blockquote cite="mid:561E5F51.3080504@redhat.com" type="cite">
<br>
-Eric
<br>
<br>
On 10/14/2015 9:46 AM, Tim Dudgeon wrote:
<br>
<blockquote type="cite">I'm wanting to do something that may not
be possible :-)
<br>
<br>
I have a service that I want to offer to multiple organisations.
<br>
I want the users of each organisation to authenticate according
to the
<br>
needs or that organisation (e.g. against their own LDAP server).
<br>
I do not want to have to handle API keys as I have lots of
organisations
<br>
and lots of services and lots of versions of those services, so
think
<br>
managing those keys will fast become a nightmare. I am happy to
use the
<br>
service as a public service, as long as the user is
authenticated and
<br>
authorized.
<br>
<br>
e.g. I think what I want to do is create an application in each
<br>
organisation with a policy that does the authentication, and use
a
<br>
public service that does the authorization based on expected
role
<br>
granted to the user.
<br>
But the only way I can see to do this is to use plans, which
involve the
<br>
need for API keys.
<br>
<br>
Any ways to do this?
<br>
<br>
Tim
<br>
<br>
_______________________________________________
<br>
Apiman-user mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Apiman-user@lists.jboss.org">Apiman-user@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/apiman-user">https://lists.jboss.org/mailman/listinfo/apiman-user</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>