First let me explain my desired solution:
I'm making a custom Credential Provider to authenticate a user by sending logon credentials to an external authentication server, then passing the same credentials along with some extra authentication parameters back to the Credential Provider. The Credential Provider then sends these credentials to the Local Security Authority which in turn authenticates the user based on a custom Authentication Package.
I am quite new to programming in Windows, but I've been studying the Credential Provider Technical Reference, so I have some understanding of how it works. What I haven't figured out yet is this: when programming a custom Credential Provider, can I program it to communicate externally like proposed in my example above? I have read somewhere that I can use WinHTTP to send data to and from the Credential Provider. Is this correct?
Regards,
bagzera
First you need to implement the IConnectableCredentialProviderCredential interface which provide a function which called Connect (this method will be called just before GetSerialization) so in this function you can make a connection to your authentication server
I have written such provider before. There is no problem in using WinHTTP to communicate with external entities. You might run into some issues with HTTPS if you have unsual SSL requirements. All you need to do is to load certificates into the correct stores.
Related
In Azure DevOps services, when you connect an agent to the server, you have different types of ways to authenticate to the server. You can see here for example, about connecting a Linux agent, that you have these 4 types:
Alternate (Basic authentication)
PAT
Negotiate - Connect as a user other than the signed-in user via a scheme such as Kerberos or NTLM.
Integrated - Not supported in Linux
The integrated type is mentioned in the page about connecting a Windows agent as "Windows default credentials"
Bare with me please.
In my organization, we have a Active Directory domain with a Single-Sign-On, I suppose it uses Kerberos as the authentication protocol. Sometimes I use Powershell scripts to access the API of our internal Azure DevOps Server, and I use the -UseDefaultCredentials flag so the user won't have to enter username and password - it will just authenticate based on the logged-in user.
That got me thinking that the -UseDefaultCredentials flag is using Kerberos to authenticate.
But from the above, it seems that Integrated is using "Default credentials", which is something else than "Negotiate" which uses Kerberos.
Can someone help me understand this?
The UseDefaultCredentials flag tells the underlying system to try and use the caller's SSO credentials, which in most cases is the credential used to log into the system interactively or otherwise.
Strictly speaking it does not indicate which protocol to use. What it's actually saying is "dear system internals: please figure it out for me". The way this works is by selecting the negotiate protocol, which as it's name suggests negotiates the use of specific authentication protocols based on the client credentials as well as information from the server. This is called the SPNEGO protocol. It is transparent to the caller.
SPNEGO is fairly simple in nature. The client has a list of known authentication protocols (Kerberos, NTLM, etc.) and will send that list to the server saying 'pick one please'. The server can select any of them and respond telling them what to use, and the client then goes and uses it. Fin.
SPNEGO is also relatively smart because it can reasonably predict what it thinks the server will accept and will attempt to optimistically provide a token up front using the first protocol in the list. So if it thinks it needs Kerberos it'll go and get a Kerberos ticket up front and send it first. The server might think that's fine, or it might fail and return a response saying
"no, I really need NTLM", and so the client tries again with NTLM.
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
If I set up composer-rest-server to use github authentication (as described in https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication.html), then a client of the rest server needs to authenticate against github.
If this authentication is successful, then the client acts with the business card that was specified during startup of the rest server (or with the one that was uploaded in multi-user mode).
However, ANY github user may authenticate that way! There is no control which github users may use the rest server (I would expect a configuration file with a white list etc.). Therefore ANY github user may interact with the blockchain the same way using the business card of the rest server?!
This is quite useless in my opinion. Or do I oversee something? What is the purpose of github authentication in composer-rest-server?
Before authentication there is no real access to the Business Network, after authentication there is access to add Cards to a Wallet after which there is access to the business network (controlled by ACL).
The Wallet is unique to the authenticated user, so in your github example if you open a different browser and use a different Github ID you will have an empty Wallet, and no access to the network - except to add a card.
With regard to Github it is just used as an example of a Passport Strategy for Authentication - it is used in the example docs as it is quite easy to set up and anybody can use Github. It might be useful for a public blockchain, but for many examples it might be more appropriate to use a Passport Strategy to connect to a private LDAP or Active Directory.
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.
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