I have a project that have embedded jetty with SPNEGO enabled. I would like to be able to run this project locally for development purposes (WITH SPNEGO enabled!)
My question is, is the SPN and keytab associated with a particular server at all or can I use the same set on multiple instances of my service?
Kerberos requires that both the client and server somehow figure the service principal to use without any prior contact. If you have control of both the client and server, you can use any principal you want provided you configure both sides to
use the same principal.
In the SPNEGO case, the client does the "standard" thing and builds a principal based on the hostname of the server. (i.e. I want to talk to www.foo.com, I'll try
requesting an HTTP/www.foo.com service ticket and see if the server accepts it. )
I don't know of any way to get the SPNEGO code in the browser to use a fixed service principal. So in this case you'll need a separate keytab for each server.
Related
I'm using SPNEGO in order to implement SSO solution. During the configuration, I was required to use domain user credentials in 2 steps:
In the web.xml of my application:
<init-param>
<param-name>spnego.preauth.username</param-name>
<param-value>myuser</param-value>
</init-param>
<init-param>
<param-name>spnego.preauth.password</param-name>
<param-value>mypassword</param-value>
</init-param>
In the setspn command: setspn -A <mySPN> myuser
When I used this configuration, the username of the user "myuser" was retrieved by the Java application using getRemoteUser(). So the SSO worked fine. But when I tried to open a session as other users (on the same windows server) it worked also, so I am a little bit confused. This led me to these questions:
Why did the SSO work for all the other users of the domain? Do I have to use the same user in both web.xml and setspn command? And which user to choose? What's the exact use of the SPN in the Kerberos scenario? Do I have to execute the command setspn in every windows computer or there is a way to do it just once?
This account is part of what defines the server's identity within Kerberos.
Kerberos is a symmetric-key protocol. Each user has a symmetric key that's shared between the user and the KDC, and similarly each service (acceptor) has a symmetric key that's shared between the service and the KDC.
When a user requests tickets for a specific "service principal", the KDC will return them encrypted using that service's key. So in order for a service to decrypt those Kerberos tickets, it also needs some way to know the key associated with its own service principal.
Often, the service key is generated randomly and provided through a "keytab" file. However, in Active Directory systems, most service accounts are regular user accounts which have a password – so their key can be derived from the service's password instead.
It seems that your SPNEGO module supports both methods (see lines 150-160) – it can be given a keytab or a password.
In any case, the setting has absolutely nothing to do with the clients that will be connecting to your service. It only establishes the server's own identity.
What's the exact use of the SPN in the Kerberos scenario?
It's similar to the domain name field in HTTPS certificates. For example, when a browser performs Kerberos authentication to https://example.com, it will always request a Kerberos ticket for the SPN HTTP/example.com from the KDC.
If you're familiar with OAuth2 or SAML or JWTs, I believe the Kerberos SPN would be the rough equivalent of the "audience" field in SAML assertions, or the "aud" field in JWTs.
(Note that the browser only knows your service by its SPN, and doesn't care about the actual service accounts that are used behind the scenes – e.g. Active Directory happens to map SPNs to real "user" accounts in this case, but other Kerberos implementations do it differently)
Do I have to use the same user in both web.xml and setspn command?
Yes, it needs to be the same user, because the service must be able to decrypt tickets that were issued for its SPN, so it needs to know the same symmetric key.
And which user to choose?
Create a new, dedicated account just for that service. Do not use a real "person" account.
Use a long, highly random password, and mark it as non-expiring. Additionally, make sure to enable both "Account supports Kerberos AES xxx-bit" features in the account's options (assuming your Java SPNEGO thing supports AES, which it really ought to).
Do I have to execute the command setspn in every windows computer or there is a way to do it just once?
No, it doesn't matter where you execute it, because it only edits the actual account on the domain controllers – it leaves no trace on the local machine. (Specifically, it sets the servicePrincipalName LDAP attribute for the provided account.)
Clients only recognize your service by its SPN, and they have no need to know about the account mapping that's done by the KDC behind the scenes.
Below is my scenario:
Client is connecting to intermediate service and intermediate service is connecting to the target service. I want to use the client credentials from the intermediate service to connect to the target service.
I used the below code in the intermediate service to acquire the credentials of the client.
GSSCredential clientCredential =((ExtendedGSSCredential)intermediateServiceCreds).impersonate(clientGSSName);
Establishing the context is failing with
NOT_ALLOWED_TO_DELEGATE
Do I need to set any flags while creating the principle of the client, intermediate service and target service? I don't want to make code changes in the client to set the credential delegation to true.
Looks like your intermediate service principal is missing "ok_to_auth_as_delegate" attribute. https://web.mit.edu/kerberos/krb5-devel/doc/admin/admin_commands/kadmin_local.html#add-principal
Is it possible to do federated identity between multiple instances of IdSrv3 using OpenID Connect/OAuth2 in the following scenario?
Multiple instance of IdSrv3, called Local STS, running on different machines with some kind of chain of trust to a Central STS. The machines running the Local STS can go offline and in that context the applications running on the local machines makes call to local STS for a token and uses that token while communicating with APIs on another server. The API Service, which is registered and connected to the Central STS, can validate and trust the token generated by a Local STS. Is it possible to do this setup with IdSrv3 or IdSrv4? Also how can a chain of trust be established between central and local STS?
That is absolutely possible -
in IdentityServer you can add external providers via ASP.NET (Core) authentication middleware. For the "other" IdentityServer this becomes a normal client.
https://identityserver.github.io/Documentation/docsv2/configuration/identityProviders.html
My web application is currently configured to connect to LDAP for user validation without relying on application server settings. In other words, my applications utilizes naming params to connect to LDAP hence its agnostic to application server ie. JBoss or Websphere.
Naming params used are as follows:
ldapURL
ldapPrincipal (bind user)
ldapCredentials (bind user's password)
ldapAuthentication
ldapSearchBase
The requirement now is to allow encrypted password in the ldapCredentials naming param. I have a way out of this situation is using custom SecurityLoginModule to encrypt password and supply it to application using naming param. My application would then decrypt it and then proceed with LDAP user validation. However, this results into additional application installation step.
So I was wondering if there is a way to use application server security domain (or some other way) to store the user credentials in secured fashion on application server and later application would pick it up at the time of user validation with LDAP without writing server specific code in my application. I know that we can use security domain to perform data source connection without writing server specific code. But if I do this for LDAP then I make server talk to LDAP which is not what am looking. Basically may still continue to use Federated users instead of LDAP.
Any decent application server (including JBoss and WebSphere) have server provided LDAP registry, which you can configure and use without any application specific code, and I'd strongly suggest to utilize that instead of writing your own ldap connection code.
Regarding encryption:
for WebSphere traditional, you can plug in your own class into server infrastructure to encrypt passwords see - Plug point for custom password encryption
for WebSphere Liberty - you have out of the box support for aes and hash.
for JBoss first link in Google showed me this How do I encrypt the bindCredential password in Wildfly, but maybe JBoss experts will guide you to something different.
I used OWSM policy Oracle/wss_http_token_service_policy on the rest based proxy service, it is working fine (authenticating with basic.credentilas) in my local machine weblogic server but not supporting in the dev/test server, so what extra setting is required here? or do we need to use any other policy, I want to use just the basic authentication configured in my realms. Could you please advise.