8:46 a.m.
I'm wanting to do something that may not be possible :-)
I have a service that I want to offer to multiple organisations.
I want the users of each organisation to authenticate according to the
needs or that organisation (e.g. against their own LDAP server).
I do not want to have to handle API keys as I have lots of organisations
and lots of services and lots of versions of those services, so think
managing those keys will fast become a nightmare. I am happy to use the
service as a public service, as long as the user is authenticated and
authorized.
e.g. I think what I want to do is create an application in each
organisation with a policy that does the authentication, and use a
public service that does the authorization based on expected role
granted to the user.
But the only way I can see to do this is to use plans, which involve the
need for API keys.
Any ways to do this?
Tim
8:57 a.m.
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).
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.
-Eric
On 10/14/2015 9:46 AM, Tim Dudgeon wrote:
I'm wanting to do something that may not be possible :-)
I have a service that I want to offer to multiple organisations.
I want the users of each organisation to authenticate according to the
needs or that organisation (e.g. against their own LDAP server).
I do not want to have to handle API keys as I have lots of organisations
and lots of services and lots of versions of those services, so think
managing those keys will fast become a nightmare. I am happy to use the
service as a public service, as long as the user is authenticated and
authorized.
e.g. I think what I want to do is create an application in each
organisation with a policy that does the authentication, and use a
public service that does the authorization based on expected role
granted to the user.
But the only way I can see to do this is to use plans, which involve the
need for API keys.
Any ways to do this?
Tim
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
10:17 a.m.
On 14/10/2015 14:57, Eric Wittmann wrote:
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).
Yes, I understand why that is necessary.
This is because the service is being called directly through the service
owner's "path". e.g.
/apiman-gateway/ServiceOwnerOrg/service/1.0
Might it (in principle) be possible to access the service through the
the application owners "path" e.g
/apiman-gateway/AppOwnerOrg/AppName/ServiceOwnerOrg/service/1.0
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.
Yes, that might work. A sort of delegating authenticator that delegates
to the appropriate realm based on a header param.
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.
Tim
-Eric
On 10/14/2015 9:46 AM, Tim Dudgeon wrote:
> I'm wanting to do something that may not be possible :-)
>
> I have a service that I want to offer to multiple organisations.
> I want the users of each organisation to authenticate according to the
> needs or that organisation (e.g. against their own LDAP server).
> I do not want to have to handle API keys as I have lots of organisations
> and lots of services and lots of versions of those services, so think
> managing those keys will fast become a nightmare. I am happy to use the
> service as a public service, as long as the user is authenticated and
> authorized.
>
> e.g. I think what I want to do is create an application in each
> organisation with a policy that does the authentication, and use a
> public service that does the authorization based on expected role
> granted to the user.
> But the only way I can see to do this is to use plans, which involve the
> need for API keys.
>
> Any ways to do this?
>
> Tim
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
12:44 p.m.
Yes, I understand why that is necessary.
This is because the service is being called directly through the service
owner's "path". e.g.
/apiman-gateway/ServiceOwnerOrg/service/1.0
Might it (in principle) be possible to access the service through the
the application owners "path" e.g
/apiman-gateway/AppOwnerOrg/AppName/ServiceOwnerOrg/service/1.0
Not at present. It's technically possible, but would require some core
changes to how the gateway processes the inbound request.
Yes, that might work. A sort of delegating authenticator that
delegates
to the appropriate realm based on a header param.
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.
One possibility is that each Organization that wants to 'consume' the
service could create their own version of it. This would allow each Org
to configure the service with whatever policies are necessary. Each
org's service would simply point to managed endpoint of the canonical
service in apiman.
For example:
* Organization "Foo" publishes a public service named "bar"
-> the Implementation endpoint is set to http://real-api.com/bar
-> service is configured with some policies, optionally
* Organization "A" publishes a public service named "bar"
-> the Implementation endpoint is set to
http://apiman:8080/apiman-gateway/Foo/bar/1.0
-> org-specific policies can be configured here
* Organization "B" does the *same* thing that A did, but with different
policies
* Organization "C" does the *same* thing that A did, but with different
policies
* Etc
Note: apiman 1.1.8.Final has a bug in the CachingESRegistry which will
actually cause the above to fail, but it will work fine in 1.1.9.Final
-Eric
3142
days inactive
3142
days old
3 comments
2 participants
participants (2)
-
Eric Wittmann -
Tim Dudgeon