Our team is currently looking to use Rancher for a Docker container orchestration solution, and one the things I'm looking to do is try setting up Access Control on the Rancher server using a provider that isn't supported by Rancher at the moment (this being Fiware Lab which can be a OAuth provider).
Rancher handles authentication in a separate Golang service available in this repo. This could be extended to allow for a new provider for authentication as described in the wiki of the repo. What I'm confused about however is how I could then deploy my extended service with Rancher Server. Is it possible to just run the extended service without having to build a new Docker image for Rancher Server altogether?
It is an external service mainly to make it easier for us to develop additional providers, and to pull that code out of the Cattle core (the migration of which is on-going, only Github is moved and Shibboleth was added as a new one only into the Golang one).
While it is possible, this is not currently a general public plugin point. There is not any formal way to register your own provider, get that into the server container, provide UI to configure it, or log into it once configured.
Related
I am trying to add an ASP.NET 4.x app hosted externally (using AWS Elastic Beanstalk) into the Service-registry of an existing PCF.
Edit: Is this possible? If so, can someone give me an example about how this can be done
Assuming you have network connectivity in all directions between apps in PCF and the external app, yes this should be quite possible.
However, if you're using Spring Cloud Eureka, your externally-hosted app will need to get valid OAuth credentials so that it can authenticate prior to registering.
The comment by Daniel Mikusa is very appropriate for how I achieved this.
For Pivotal SCS, you would want to create a service instance (if you
don't have one already), then create a service key for your external
app. That will give you all of the binding info/creds you need to
connect from your remote service. A service key is the same as binding
a service to an app, except it's not tied to an app so it works well
for situations like this. Just give your service key a good name, so
you know that it's being used by an external app when you come back
and see it a year from now
The kubernetes-go client provides a subset of the functionality that is present in the openshift API.
It would be desirable that programs running on kubernetes could easily run on openshift as well, so long as the APIs were compatible.
That being the case, can we then access the openshift API using a pure kubernetes client written in golang, or does openshift need to modify the client functionality (even for simple API post/watch operations).
We have to develop a larger application with an Angular App on top and a lot of ASP.NET Core based Microservices under the hood.
Also we have to support external applications.
The external applications can be services without UI and also user GUI client applications.
Now the requirement is, that all internal Microservices are auto-trusted automatically and only for external Application the user should get the trust workflow in IdentityServer.
We're not sure how the workflow here should be configured or is be named in this scenario.
I think we need two different workflow configurations for internal and external application trusts.
Can anybody push me into the right direction which workflow and configuration fits most to our requirement?
Following providers we have to support:
- Simple Forms Authentication for our platform
- External Azure Active Directory
I have a mule service, named IS, deployed on mule runtime and proxied on API gateway. I'd like to set up different policies to the IS and its proxy service. How can I do it?
My environment:
Mule runtime: 3.7.4
Mule API gateway: 2.1.1
The following are two valid and equally correct solutions that you can choose from, taking into account that your implementation API is a Mule app:
Create an API on API Platform
Solution A:
Configure the autogenerated proxy to use your implementation API URL
Deploy the proxy to a correctly configured API Gateway/Mule runtime
>= v3.8.0
Apply one or more policies to the tracked proxy
Solution B:
Add autodiscovery to your implementation API, using the same API
name and API version name than your already created API on API
Platform
Deploy the impl app to a correctly configured API
Gateway/Mule runtime >= v3.8.0
Apply one or more policies to the tracked implementation app
With solution A, you have to make sure that your implementation app is only accessible by the proxy app (eg with a firewall).
If your implementation API would not be a Mule app, then Solution B would not be possible.
We can create endpoint with a proxy or select Basic endpoint if you create your API outside API Manager, for example, you created the API using Mule ESB. You don’t need a proxy in this case. So policies will be applied to API. For more details go through the link.
https://docs.mulesoft.com/api-manager/setting-up-an-api-proxy
If you're using Mule runtime v3.8.x, and if the service is an HTTP/S listener, you can actually make it auto-discovered in the API Manager and have policies applied directly on it, even if the mule config is not generated using APIkit.
https://docs.mulesoft.com/api-manager/api-auto-discovery
Choose the flow that you want the API Manager to manage and apply policies.
Do note that you will need to have to right entitlement (API Gateway) in the Mule Runtime license and that it has the right Anypoint Platform Client ID/Secret pairs configured in the wrapper.conf. The IDs should be automatically configured if you've added the Mule Runtime server in the Anypoint Runtime Manager.
Here is my solution to apply policy to proxy service:
Create a new API using proxy service's url
Apply policy to API created in step1
Can anyone confirm this is the correct way?
I am using new feature of Azure that enables the active directory authentication for your website without writing any code.
http://azure.microsoft.com/blog/2014/11/13/azure-websites-authentication-authorization/
But the problem is my web application is also hosting some Web APIs, which need to be called without any authentication.
Is there a way (some attributes?) so that I can call Web APIs without any authentication?
Tushar, I see that Byron also replied to your question on his post- and suggested creating another website as for APIs as a work around. However I suggest that you wire-up auth separately for your Web App and APIs following our samples here: https://github.com/AzureADSamples/WebApp-OpenIDConnect-DotNet, https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
Let me know if you run into any issues.
From the very same article you refer:
Current Limitations
There are some limitation to the current preview
release of this feature:
...
With the current release the whole site is placed behind login the
requirement.
Head less authentication/authorization for API scenarios
or service to service scenarios are not currently supported.
So, no, you cannot have partial APIs or pages anonymously available - all pages and API will be protected by the Azure Active Directory.