I have been looking into whether it is possible to use Shibboleth/SAML with Amazon Web Services.
I'm finding very little information on this. As far as I can tell, it is possible to install Shibboleth/SAML on an EC2 server as a Service Provider.
What I am not so sure on is whether it is possible to tie all of AWS to Shibboleth - and how this would work.
My knowledge of all three are vaguely fuzzy - I've been doing a great deal of reading, but I'm not really familiar with this technology at all.
If I understand you correctly, what you are trying to do is use identity federation to grant a user temporary security credentials to perform AWS api calls. You would like your users to authenticate to your own identity provider (Shibboleth in this case), and be granted access to AWS services based on that authentication.
A good example of this that you can use as a framework is in this AWS sample code.
In a nutshell:
You need a proxy that the users connect to, passing in their authentication credentials. You would then verify them by authenticating to Shibboleth, AD, LDAP or whatever.
You need a Token Vending Machine that your proxy would then call to get a valid AWS secret key using GetFederationTokenRequest.
Your client would then use the token given to it to make the AWS api calls.
The concepts of federated identity include terms like STS, SP, and IdP, if you are looking for a starting place to research the topic more.
Related
I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.
I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.
Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.
All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.
Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.
From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?
Can anyone out there provide a bit of guidance?
Thanks.
You have misunderstood how the audience URI works.
It is not your client's URI, it is your API's URI.
When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource.
That will then be the audience in the token.
Your API only needs to check the token contains its App ID URI as the audience.
Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions.
Then your API should also check that the access token contains something like:
"roles": [
"your-permission-value"
]
It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant.
But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.
It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients.
All of that can be automated with PowerShell though.
I have configured composer-rest-server. I had also provided fabric username/password while configuring composer-rest-server (WebAppAdmin or admin). Now, I can able to access REST API without providing any credentials (through postman or loopback).
I would like to understand how we can secure composer-rest-server. Though, I have understood that we can add participant and issue identity, but not able to connect logical dots in context of how everything will work.
How to secure composer-rest-server while accessing REST API?
When and How we are going to use "username/secret" registered against any participant?
When to authenticate composer-rest-server API and When to use participant identity to access business network?
Please see the documentation on this subject:
https://hyperledger.github.io/composer/integrating/enabling-rest-authentication.html
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.
I am to be having a lot of problems, misinformation and confusion when attempting to find out the plausibility and viability of attempting this.
The requirement is for a remote client, accessing our website to be auto signed in with their Active Directory User account.
We have the option to setup a WCF service (or something similar) on their remote server for authentication purposes. Which from my little understanding is how this problem will be tackled.
So, my question after a little background is this.
CAN this be done, and HOW can it be done?
Instead of hosting a WCF service on their domain, I would look into installing ADFS on their domain.
You can change your website to accept security tokens from ADFS using the WS-Federation protocol. You can use classes from the System.IdentityModel namespace for that. An example of how to implement this in ASP.NET can be found here.
An alternative would be to use Azure Active Directory as your identity provider and have your client sync accounts to their AAD directory (or federate between AAD and ADFS). An example can be found here.
I am designing a service to handle authentication across a number of hosted platforms. This service will need to be able to manage a number of different protocol for the users: LDAP, Shibboleth, no doubt others.
I was hoping to use the Shibboleth protocol internally and run the service as a Shibboleth IdP where depending on user category, nature of the protected resource, etc. the hard work of the authentication is passed on to the native LDAP, Shibboleth, or other server where the user already has an account.
It seems as though this should be possible, but I have not gotten sufficient clarity from the Shibboleth documentation to work out whether it is, let alone how to do it.
Is this possible? How do I do it? Useful documentation very much appreciated.
Shibboleth is not a protocol; it is the name of the software stak that uses the SAML protocol.
Shibboleth can authenticate users from LDAP, AD (and database via a JAAS plugin).
Documentation on hooking up Shibboleth to use LDAP for authentication and attribute retrieval is at: https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverLDAPDataConnector