Postdatable Kerberos tickets in Java - java

I need a postdatable Kerberos ticket in my Java application. But I did not find any method in the GSSContext interface. Does Java not support this Kerberos feature?
The purpose is as follows:
In our application, users can set up a batch that will run some time in the future. And the application server will have to use a delegated ticket that is valid at execution time of teh batch, when the original ticket may have expired.
EDIT: To clarify my first statement: I found that GSSContext, GSSContextImpl as well as the GSSContextImpl do not give access to the setAuthTime() method which is only available in Krb5Context. Without having dug into all details, it seems the postdated authentication would only be possible with some direct access to undocumented classes.
As there seem to be additional problems in getting a client browser to send a ticket with the correct flags set - as #Michael-O pointed out -, I think I will have to find another solution, maybe just asking the user for username and password, saving them encrypted with the batch, and then just requesting a new ticket at batch start time.
The concept of postdated tickets sounds appropriate for my problem, but there seems to be a lack of practical use, resulting in it not being well supported by existing environments.

Besides my comment:
Frank, did you actually read chapter 2.4 of the RFC4120?. The TGT from the client must have the initial flag MAY-POSTDATE. Please check that first. Yes, Java GSS supports that but I haven't tried that myself. See this search.
Frank, there is a solution to your problem. Just came to me yesterday. I have answered this already. It may be a bit of work to backport this code but it is worth it.
See Generating AD Kerberos tickets without user password.

Related

Is there any hook or call back when a user is deleted from auth0 dashboard?

Is there any, way to create hook or call back that Auth0 will trigger once a user is deleted using the auth0 dashboard?
Thanks
No, such a feature does not exist today (26/09/2017). However, you are free to write your own API for example, that will retrieve an API Management v2 token, use that to call Auth0 API and delete a user, then perform whatever (web) hook operation you had in mind. Make sense?
If you can explain further your scenario, and why you were asking for such a feature, may be able to offer an alternative that addresses your requirements.. Please leave me comments below if you like.
Ok, based on your last round of comments - please take a look at Auth0 Custom DB Connection. This might be what you are looking for - note here, the specific questions you are asking would make more sense where you are NOT migrating your users over to Auth0 if you wish to use the Dashboard for delete operations. For an Auth0 custom db connection, where you are not migrating users, then you can write a Delete script that would be triggered from dashboard.

Authorizing using WSO2 permissions

WSO2 seems to support 2 scenarios/models of authorization (e.g. as explained here): First is Database based Permission Store and the other is XACML based authorization using defined policies. The first allows you to define permission in a nice UI tree per each role while the later requires more complex policy definitions (but more flexible as it is fine grained permissions).
As far as I found it, those are separate mechanisms, and XACML queries does not consider the permissions defined by the first method. Since I need to support a simple RBAC model, I wish to concentrate on the first kind.
Using Java, I have found how to use the SDK to check the user decision using EntitlementServiceStub SDK, however I failed to find the SDK that can be used to check if the user has permissions of the first kind (I was just able to get the UI definitions, but I'm looking for something that can answer what is the decision/result, e.g. given "user1" & "/permission/protected/server-admin/homepage" can answer "true" - I suspect RemoteAuthorizationManagerServiceStub but not sure it is).
What is the SDK I'm looking for?
According to the post, it claims that database permission store is only available for Carbon based Server. And I think you are trying to do the same for identity server. In the documentation, it is not mentioned which means it does not support this feature for identity server

Setting a review policy when creating Mechanical Turk HITs in bulk

I'm using the Java API for Mechanical Turk and I'd like to give a review policy to HITs.
This blog post mentions that you can provide an answer key to a HIT question and set a review policy such that the HIT will be automatically accepted or rejected based on known answers.
I'm currently using the createHITs methods in com.amazonaws.mturk.service.axis.RequesterService to create HITs in bulk. Under this set of methods, I can't find a way to provide an answer key, and load the answers in bulk from an input file.
I've looked into a few more classes (like HIT and RequesterServiceRaw) for a way to change created HITs and add a policy to them - can't find anything.
Finally I thought I might be able to provide a review policy through the HITProperties, but that doesn't seem doable either.
Any ideas?

Java Security class and Providers

I'm having trouble understanding how certain parts of the Security class work.
I understand that calling getProviders() will return all of the providers available on the current Android device. What I'm having trouble understanding is how to make use of these providers' algorithms for encryption/decryption.
The Security class also has a setProperty() function. The documentation doesn't go into much detail about how this works, but it seems like I can set any made up property here with any value that I like. How would I actually check that a change took place on my device after setting a specific property?
If anybody could point me to a resource online that goes into detail on this topic I would appreciate it.
EDIT:
I'll be more specific. I'm trying to take advantage of a FIPS-compliant device. There is a specific property that needs to be set using the setProperty() method to enable "FIPS mode" on the device.
I'd like to figure out how I can confirm that the device is running in this mode after the property is set, and how I can utilize the available FIPS validated algorithms.
On your "encryption/decryption" request, if you are referring to store data in an encrypted/safe way in the device (i.e. data at rest, opposed to data on transit), I think https://developer.android.com/about/versions/android-4.3.html#Security - KeyStore is one good and apparently easy solution. That way you will follow the Android way, if you want to follow the standard Java way there are tutorials for that as well, but I discourage as the possibility of adding a mistake is very high. Crypto is kind of difficult for anyone...
For data in transit (i.e. network) you should rely only on HTTPs (or pure TLS if you use something different from HTTP - this hardly happens) rather than any ad hoc implementation, unless you really need an additional layer (i.e. a secret protocol you want to protect).
If you want to make sure that a specific algorithm is used, you can specify the provider in the getInstance methods. Another option is to place the provider first in the list of installed providers. If you just want to use the provider for private and secret keys you can also put the provider in the end of the list and rely on delayed provider selection. This actually links the underlying CipherSpi during the initialization phase, after the compatibility of the key with the provider has been established.
With regards to the question in the edit, that depends on the provider. I don't think that there is anything specific in the security architecture to make sure FIPS mode is run. Instead, you should check if the Provider or the underlying implementation (PKCS#11?) has possibilities to log usage. Usually you need to authenticate before you can use private or secret keys on the token. If that is the case, not having to provide a password (using a call back) is a pretty good indication that the key isn't accessed.

How to set up several user roles for existing java desktop app?

We have a system that comprises of several functions and I am requested to separate some functionality from our existing system.
Basically, the system have only one user which has access to the whole system functionality, however, the requirement here is to limit the access some users have to the system.
I would appreciate some kind help in the direction i am suppose to take with this assignment.
Thanks in advance
PS if its not clear enough you can follow up by comment.
The first question you need to answer is - where do you want to keep your access information? i.e. who can access what. some options include a LDAP server, hard coding into the app, or some sort of encrypted file, etc. How you asnwer this will dictate the technology you use.
For example, if you decide to use a LDAP server, then you need to have your app setup a connection to it, prompt the user for a userid and password, logon, and retrieve their security groups. Then when you are setting up the GUI, you can query the retrieved groups to see what the user can see or access.
It's pretty much always a good idea to relate a user to one or more security groups. From there you can decide to either assign GUI functionality to individual groups, or to decouple a step further and assign function to privilages, and then define group to privilage relationships.
Java comes with JAAS which is a built in security framework. But it can take some time to get your head around and (AFAIK) is not a completely solution, just a starting point.
It also may be that you simply don't need anything as complex as LDAP and JAAS. If it's a simple app then perhaps you only need an admin id which only one or two people know the password to, and some shared other ids, in that case you can simply store the data in the app. Although this is the least flexible solution.
Finally you should make sure that the difficultly of accessing the system should match the importance of the information being stored. ie. don't put bank level security in front of editing the staff's contact information.

Categories

Resources