The documentation of JSON-LD mentions that clients can provide a profile parameter to the Accept header can be used to control the representation. It defines the three defaults for requesting compacted, expanded or flattened JSON-LD documents. It does also say that
If the profile parameter is given, a server should return a document that honors the profiles in the list which are recognized by the server.
It does not, however, explain whether there are any specific rules the server should follow. Is it completely up to the server to decide what the behavior is for custom profile URIs? Are there any discussions on that subject?
Would the examples below be correct?
Example 1
The client requests with
Accept: application/ld+json;
profile="http://www.w3.org/ns/json-ld#compacted http://schema.org"
And the server returns compacted document with http://schema.org as #context?
Example 2
The client requests with
Accept: application/ld+json; profile="http://schema.org"
And the server returns compacted document with http://schema.org as #context?
The JSON-LD 1.0 Spec defines profile in IANA Condierations. This defines the profile identifiers such as compacted you identified above. It doesn't provide a way to specify a specific context to use, and the semantics of profile would make it difficult to know what is meant by a different profile URI, as there is no way (AFAIK) to register this meaning elsewhere.
That said, I think it would be useful to be able to specify a context to use for compacted or expanded, and if/when we support framing, a frame to use. I think this might take the form of a type-specific Accept parameter context and/or frame, which would be used to specify the requested context or frame to be used when serializing the document. However, as with other profiles, these are SHOULD, not MUST; a client needs to be able to cope with getting a document back not so serialized, perhaps using a local jsonld.js instance to re-encoding the returned document. It might also be useful to recommend that the same parameters be used in the response with Content-Type for the server to communicate the profile/context/frame used as part of the response.
Please consider raising an issue at https://github.com/json-ld/json-ld.org/issues, as we're starting to look at new Community Group (i.e., not W3C Recommendations) drafts of the specs to address long outstanding community feature requests.
Related
I know that it is possible to control which grant types a client is allowed to use, but I want to have the discovery document exclude "implicit" from the grant_types_supported list. Just because identityserver4 supports implicit doesn't mean that my identity platform supports it. I know I can disallow all clients from using it, but I don't even want it to show in the discovery document.
I've researched this quite a bit, and while I can see that you can disable endpoints in the discovery document, I don't see anyway to alter the grant_types_supported list. I would have expected this to be documented here, but I did not find anything. The wording of the paragraph on that page
Allows enabling/disabling various sections of the discovery document, e.g. endpoints, scopes, claims, grant types etc.
implies to me that it might be possible to enable/disable endpoints, scopes, claims, grant types, etc via this section of options, but it seems that it only controls including/excluding entire sections. For example, if you set Discovery.ShowGrantTypes to false, it would exclude the entire list from the document. I just want to remove the one item for implicit grant type.
This isn't configurable in IdentityServer4. It's hardcoded in the DiscoveryResponseGenerator.CreateDiscoveryDocumentAsync method.
The only solution I can see is to override this method, call into base, and then modify the resulting dictionary.
I have been assigned a task to export the AD Attributes than find out what systems are using these attributes. I have not had much luck in scripting or a tool that can provide just that. Is this feasible and if so how? I have already exported attributes. Just need to find what systems are using them.
This isn't possible with any reasonable accuracy, especially if "using" isn't defined for you.
The event logs on the domain controllers will tell you where login events are coming from, but only by IP. That doesn't tell you which application is authenticating. You would have to do monitoring on that computer and see which application is making the connection. But then the logs would be cluttered with connections made by Windows itself, or Exchange (if you use Exchange for email). It it would be very difficult to identify what is coming from an 3rd-party application rather than Windows itself.
Also, applications can request more information than they need. It's very easy when programming with LDAP to request every attribute for an object, even if you only intend to use one. For example, take this C# code:
var de = new DirectoryEntry("LDAP://example.com");
Console.WriteLine(de.Properties["name"].Value);
That only "uses" the name attribute. But because of the way LDAP works, it actually requests every non-constructed attribute that has a value. (there is a way to specifically ask for only one attribute, but you have to know that and use that)
So even if you could find logs saying that "this IP requested all of these attributes", and then figure out which application made that request, that doesn't mean it "used" all of those attributes.
We are using a akeneo/pim-community-dev installation in version 1.6.23. We are hosting this instance on platform.sh. Since platform has updated their WAF, we now can't update large datasets because the ajax request is invalid. The support of platform told us, that the request being made by akeneo PIM is not RFC compliant. The maximum amount of keys in a form-urlencoded send is 4000 according to the RFC. Since they did not specify a key, every character gets recognized as a key. And thus it fails.
The solution would be sending the data differently. Instead of doing --data '{"code":"vgrp_dur..... we should do --data 'jsondata={"code":"vgrp_dur.....
I actually don't know where I could change the code to do this ... Has someone the knowledge or can give me a hint?
I've found the related part of code and made a composer patch to fix it for the version ^1.6: https://gist.github.com/PaperCoder/63a62d029f7cd879b3ce1b6ac0470e0c
I added the correct contentType to the $.ajax-JQuery-Call.
I thought I understand how Kerberos works, now I am not sure at all.
We have a problem with Kerberos authentication on a 3rd party server with Windows Active Directory. The server support is insisting that what they call "kerberos server" passes additional information somehow, namely fields identified as uid and email, and I need to confirm that they are indeed "sent" by the server before they can help any further. I read "kerberos server" as the KDC, which "sends" information by placing it into the TGT, and the uid may be the good old UPN, except I do not understand why I am asked to confirm it is really there. But what is the email attribute?
I even read the whole RFC4210, but could not find any possible place for additional info in any of the tickets. In general, 1.5.2 talks about extending the protocol, but in the very abstract manner. There are also KRB_SAFE and KRB_PRIV messages, that can be used to pass arbitrary octet strings (3.4, 3.5), but no step towards defining their structure is done in the standard. There is also padata extension, that 5.2.7 notes have also been used as a typed hole with which to extend protocol exchanges with the KDC., but this seems sent one-way. And nowhere the RFC seem to talk about additional identified fields that the authentication server can attach to the ticket.
My question is thus bifold:
Theoretical: how additional attributes are passed in Kerberos, presumably in an interoperable way (not e. g. Active Directory extensions)? What am I being asked to confirm?
Practical, if anyone can help with that: how to track what is placed by the AD into these attributes?
The server support is very lousy at telling you what they really want to have. Here is what you need: You want the KDC to send you PAC data with the generated service ticket. Here is Microsoft's reference: https://msdn.microsoft.com/en-us/library/cc237917.aspx.
How to verify? You need the a keytab for the account which is accepting the security context. Configure that with Wireshark, log all traffic. You should see the TGS-REP for the service you'd like to use. Expand it, when the keytab is fine, you will see the decrypted information. Somewhere down below, you should see the Authorization Data fields, type 1 (AD-IF-RELEVANT). That is an ASN.1-encoded sequence of elements. Even element position describes the sub type, odd element position the octet string. In that octet string is again an ASN.1-encoded suquence with type 128 (AD-WIN2K-PAC) and that is the PAC data. Unfortunately, Wireshark can decode upto level one only. The request is an opaque byte buffer. I have minimal, working (though incomplete) Java implementation of the PAC data decryption.
The email value is not included in that structure but what you have is the RID KERB_VALIDATION_INFO structure and the userPrincipalName in the UPN_DNS_INFO structure. The latter is extremely easy to decode.
First check via LDAP that for the desired client account userAccountControl does not has the NA field set.
Godspeed.
How would one create a REST web service to write a row into a databse table. Use the follwoing scenario:
The table is called Customer - the
data to be inserted into the row would
be the name, addresss, telephone
number, email.
I think its impossible to describe the whole thing end to end in Java or C#, and I would never expect that, but here are the questions I have popping into my head as I prepare for coding:
How the URI would look (eg. if you use this URL - http://www.example.com/)?
What info would go into the HTTP envelope?
Would I use POST when writing to the database in this way?
Do I use a resource to store the posted data from the client? Is this even necessary if the data is being written to a database anyway?
When the data to be writeen into the db is recieved by the server - how do I physically insert it into the database - do I call some method on the server to actually write the data (in Java)? - this doesn't seem to fit with truely REST architecture - shunning RPC calls.
Should I even be bothering writing to a DB - should I be storing my data as a resource?
As you can see I need a few issues clearing in my head. Any help much appreciated.
First of all, I'm not either java nor c# expert and I don't exactly know what means do these languages have to support REST design, but in general:
http://www.example.com/customers - customers is a collection of resources and you want to add a new resource to this collection
It depends on various things - you should probably set the content-type header (according to the data format in which you are sending the representation) and set some authentication headers if you need it.
Yes, you always use POST to create a new entry in a collection of resources.
I don't fully understand this question, to be honest. What do you mean by "inmediately writing data into the database"?
REST is primarily just a style of communication between server and a client. It doesn't say anything about how you should handle the data received by using it. The usual way how modern web approaches (MVC style frameworks) solve it, is by routing every REST action to a method of some class (usually a controller instance) where you handle the received parameters (eg. save them to the database) and generate a response to be sent back.
For a very brief and very clear introduction to REST have a look at this short video.
RESTful Web Services, published by O'Reilly and Associates, seems to fit the bill you're looking for.
As far as doing it in Java, Sun has a page on it.