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
Related
I am using Spring Specification (and net.kaczmarzyk.specification-arg-resolver for auto spec creation) to make dynamic Endpoints.
I have run into the need to know if a specific Specification exists on the request already (both for testing and permissions).
Permissions:
Based on user access I sometime append specifications onto the requested on. However it would be nice to know if specific spec's were used and maybe even update or delete them.
Testing:
Would be nice to know after a function has run to validate if a spec got added like it should have.
We generate our swagger/openAPI documents based on annotations in our java code. There are end points in the code that are there just for our internal usage. These are endpoints that we don't want accessible or even visible publicly.
It's possible, I guess that we could post process the swagger file and remove these endpoints, but that adds another step in the build process. What would really be nice is if could just tag them in such a way that the google cloud endpoint load-balancer saw the tag it would ignore the endpoint. Is such a thing possible?
I imagine we could do something like this by identifying them as requiring access, and then not configure anyone to have access, but I wondered if there was another path that might yield the same or better results.
Right now you can only manage who can access your endpoint with
API keys
Firebase authentication
Auth0
Service accounts
but this is only to authenticate, however what you want to accomplish is not possible at the moment, I could suggest you create a feature request. So the GCP team knows you are interested on the functionality and maybe implemented on the future.
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.
This is going to be a bit open-ended initially. My team has a requirement to utilize Oracle Label Security (OLS). Because we would like to enable "fast" search capabilities (Solr/Lucene) how can we correctly retrieve data that is cached (Lucene/ Solr) based on the OLS policy in place?
One way you can use external systems like your OLS is Solr's PostFilter interface. A very good write up how to do use this has been published in the article Custom security filtering in Solr by Erik Hatcher.
Basically you have a hook after all search and filtering has been done. There you can open a connection to your database and filter the search results according to the user's access rights.
To speed this up, you should consider to place some security relevant artifacts into you index, which you then include as ordinary filter. That way you can do a pre-filtering, so that you do not overwhelm the PostFilter.
Currently there is nothing pre-build by the community, but you could kick-off something on GitHub.
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.