I have a Java API that talks to the Kerberos server and performs various operations. As of now, my API requests for non-renewable tickets to the Kerberos server. From what I understand, the jaas config file has an option to set the renewTGT option to true so that a renewable ticket can be issued. However, Jaas seems to have a lot of restrictions on setting the "renewUntil" time. Can anyone please tell me how we can request for arenewable ticket and also control its renewability? Basically, is there a way we can perform a Java equivalent of the operation : kinit -R ? Thanks in advance.
As of JDK7 (1.7.0_55), JAAS Krb5LoginModule does not provide any option to request a renewable TGT when authenticating, so this is not currently possible using JAAS. You might be able to achieve this, but you would need to use the internal Kerberos classes directly, bypassing JAAS.
Internally, Krb5LoginModule instantiates a sun.security.krb5.KrbAsReqBuilder to obtain credentials using either a provided password, or a keyTab. KrbAsReqBuilder has a setOptions(KDCOptions options) method, but this is not called in the login module. If it could be accessed, you could call KDCOptions#set(KDCOptions.RENEWABLE, true), and I would then expect the returned ticket to be renewable, if the KDC is configured to allow renewable tickets.
Related
We have installed and configured RedHat APIMan for our working API and the plan is migration form current home-grown tiny gateway to APIMan. The problem is that we have some unprotected endpoints which do not need login (Not everyone role! No login required at all). We are using Keycloak OAuth plugin for roles, and Authorization Policy for API security. When Authorization policy is not added, I can allow unauthenticated requests via a boolean value in Keycloak OAuth policy, but after adding Authorization policy, there is no way to let unauthenticated requests pass!
Kamyar. Apiman developer here.
Please file a feature request for this over at https://github.com/apiman/apiman/issues.
I think what you are trying to do may not currently be possible easily because the authentication policy is expecting a successful auth of some sort before it is hit (to get the roles, etc).
We probably need a slightly more detailed explanation of your use-case, and then we can figure out whether we can support it. It seems like it should be doable without major changes if I understand correctly.
If and when we add support for the specifics of your requirement, I will endeavour to update this ticket.
I’m automating a service that needs to access a kerberized resource.
Passwordless kinit with a keytab works fine. The resource is then connected
to using SASL.
Is there a way, maybe via GSSAPI or libkrb5, to ensure a TGT is present
whenever the resource is being accessed? Forking kinit before every access
seems the pragmatic thing to do. However, there’s an obvious race between the
time of TGT acquisition and its use to acquire a TGS that I’d like to avoid.
I imagine something like receiving an fd for authentication whose validity is
guaranteed until it is being closed by the user.
I’d prefer to stay away from heavy-duty solutions like sssd to auto-renew the
TGT.
The answer turns out to be providing the client keytab for libkrb5 in the
KRB5_CLIENT_KTNAME parameter:
If no existing tickets are available for the desired name, but the name
has an entry in the default client keytab, the krb5 mechanism will
acquire initial tickets for the name using the default client keytab.
From the MIT Kerberos docs.
The wiki also has a write-up of the implementation.
According to documentataion for WebHDFS REST API
https://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Delegation_Token_Operations
It is mentioned when security is on there is 2 mechanism
Authentication using Kerberos SPNEGO when security is on
Authentication using Hadoop delegation token when security is on
If i choose to use second option i.e Authentication using Hadoop delegation token when security is on
Does it mean it can run without Kerberos configuration in hadoop setup?
Do i have to setup Kerberos in my hadoop configuration in this case ?
To put things in context: typically, you use SPNEGO when you start your HTTP session, then cache your credentials somehow to avoid the complex rounds of 3-way communication between client, server, and Kerberos KDC.
AFAIK, all the Hadoop UIs and REST APIs use a signed cookie after the initial SPNEGO, and it's completely transparent for you -- with the exception of WebHDFS.
Now, with WebHDFS, you have to manage your "credentials cache" explicitly:
start your session with a GET ?op=GETDELEGATIONTOKEN -- you don't present any credentials, therefore it will trigger a SPNEGO authentication, then generate a Hadoop delegation token server-side
retrieve that delegation token from the JSON result
use that token to present your session credentials explicitly in the following GET / POST / PUT, by appending &delegation=XXXXXX to all URLs
Bottom line: yes, you have to set up your Kerberos configuration on client side. The delegation token only allows you to minimize the authentication overhead.
We are considering to use the keycloak as our SSO framework.
According to the keycloak documentation for multi-tenancy support the application server should hold all the keycloak.json authentication files, the way to acquire those files is from the keycloak admin, is there a way to get them dynamically via API ? or at least to get the realm public key ? we would like to avoid to manually add this file for each realm to the application server (to avoid downtime, etc).
Another multi-tenancy related question - according to the documentation the same clients should be created for each realm, so if I have 100 realms and 10 clients, I should define the same 10 clients 100 times ? is there an alternative ?
One of our flows is backend micro-service that should be authenticated against an application (defined as keycloak client), we would like to avoid keeping user/psw on the server for security reasons, is there a way that an admin can acquire a token and place it manually on the server file system for that micro service ? is there a option to generate this token in the keycloak UI ?
Thanks in advance.
All Keycloak functionality is available via the admin REST API, so you can automate this. The realm's public key is available via http://localhost:8080/auth/realms/{realm}/
A realm for each tenant will give a tenant-specific login page. Therefore this is the way to go - 10 clients registered 100 times. See more in the chapter Client Registration of the Keycloak documentation. If you don't need specific themes, you can opt to put everything in one realm, but you will lose a lot of flexibility on that path.
If your backend micro service should appear like one (technical) user, you can issue an offline token that doesn't expire. This is the online documentation for offline tokens. Currently there is no admin functionality to retrieve an offline token for a user by an admin. You'll need to build this yourself. An admin can later revoke offline tokens using the given admin API.
Is it possible to have a Java process running on linux access EWS using kerberos only without the need of a pre-defined username/password combination?
My current system architecture consists of a Java process that accesses EWS using a stored username/password combination. Requirement is to ensure that the credentials under which the Java process runs are authenticated on Exchange using Kerberos.
Is it possible to have this setup?
yes, it should be possible to authenticate to EWS using Kerberos. You can Java GSSAPI to get the Kerberos tickets (from the ticket cache or prompt the user). There is a Java GSS Sample program at http://docs.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/BasicClientServer.html
Your question seems to be more on what Java can do versus what Exchange/IIS can do. I don't know Java well at all, however I do know EWS and IIS topics well.
Here is something to keep in mind - IIS does the authentication and not EWS. You could do an HTTP GET on a file in a virtual folder on an IIS server to verify that your API works. If you can authenticate to IIS, then EWS should work. Now having said that you also need do consifer access issues - ie impersonation and delegateion - you will need to be sure you have the needed content in the EWS XML and have the correct Exchange settings for Impersonation and correct folder permissions set for delegation.
Yes, it is possible. It is already implemented in "JWebServices for Exchange", Java API for EWS
You ticket a TGT in the ticket cache or a keytab for that account.