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.
Related
I am trying to represent environment variables in the Salesforce codebase and came across Custom Metadata Types. So based on which Sandbox I am in, I want to vary the baseURL of an external service that I am hitting from my apex class. I want to avoid hard coding anything in the class, and hence trying to find out an environment variable like solution.
How would you represent the URL as a custom metadata type? Also, how can I access it in the class? What happens when a qa sandbox is refreshed from prod? Do they custom metadata type records get overridden?
How are you calling that external service? If it's truly a base url you might be better of using "named credential" for it. It'll abstract the base url away for you, include authentication or certificate if you have to present any...
Failing that - custom metadata might be a poor choice. They're kind of dictionary objects, you can add more (but not from apex) but if you deploy stuff using Git/Ant/SFDX CLI rather than changesets it'd become bit pain, you'd need different custom metadata value for sandbox vs prod. Kinda defeats the purpose.
You might be better off using custom setting instead (hierarchy is enabled by default, list you'd have to flip a checkbox in setup. List is useful if you need key-value kind of pairs, similar to custom metadata): https://salesforce.stackexchange.com/questions/74049/what-is-the-difference-between-custom-settings-and-custom-metadata-types
And you can modify them with Apex too. Which means that in ideal world you could have a "postcopy" class running as soon as sandbox is refreshed that overwrites the custom setting with the non-prod value. For named credential I don't think you can pull it off, you'd need a mini deployment that changes it or manual step (have you seen https://salesforce.stackexchange.com/q/955/799 ?)
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.
I need help for my AD Integration.
I’m using Spiceworks for the system and there is a portion there for AD Integration.
The problem is that I need to sync two different OU’s
Base DN for LDAP search:
DC=dc1,DC=dc2
LDAP user filter:
(&(objectCategory=person)(|(ou=OU1)(ou=OU2)))
And its not working.
My AD Structure is
dc1.dc2
— OU1
— OU2
— OU3
dc1.dc2 is the top level.
OU1, OU2, OU3 are on the same level.
The reason is I don’t want to include OU3 in the syncing
LDAP filters are generally only applicable to attributes that are in the user entries.
If you want to include attributes that are part of the DN (the path to entries), you need to use extensible filters such as:
(&(objectCategory=person)(|(ou:dn:=OU1)(ou:dn:=OU2)))
Note that while this is standard LDAP filters, not all servers support this.
Active Directory doesn't support filters based on OU. In this instance, it's an "extensible match filter" that some LDAP implementations support, but not all (including AD). More info here.
By the way, you can't do a wildcard search on the distinguishedName, if you're tempted to try.
To be honest, this is why it's best to have all your "person" user accounts in one OU (maybe subdivided further down), groups in another, etc. In your case, if you can, it might be a good idea to move your "synching" account OUs under a new OU. If you have a enterprise environment, you will want to be careful there are no dependencies on the OU structure before making such a change. Or that you can identify any such dependencies and fix them before or at the time of making the change.
Otherwise, you'll need to make your searchbase the root of the domain. If you have other user account attributes you can use to search, such as department names or similar, that will work. If it's employee accounts, do they all have a common field that's populated, such as "employeeID" or "streetAddress" or something? Or do the accounts you want to exclude have a specific name format (such as all the service accounts starting with "SVC")? By combining things like that, you can generally get it pretty good.
Finally, for searching normal user accounts, a more efficient basic query is:
(samAccountType=805306368)
Your query of (objectCategory=person) returns User and Contact objects. The usual way to scope it property is (&(objectClass=user)(objectCategory=person)), but the two clauses makes it less efficient than my recommendation (which is using an indexed attribute as well).
I was wondering if anyone had any information on how to change a priority on a rule in HP Fortify?
For example in C, the category "Uninitialized Variables" has the fortify priority order of LOW. I need to change to HIGH for auditing purposes. Is there any way to change a rule or do I need to create a new rule?
If I need to create a new rule, how would I make a rule that matches "Uninitialized Variables" and make it global for other users to use?
There's not really way for you to modify the existing rule pack. But that's okay. There's something much easier that I can suggest that does not involve trying to create or modify custom rules (which can get a very messy if you're not careful).
The easiest thing you can do is create a custom Folder Filter.
Open up your FPR in Audit Workbench. Select the correct Filter Set that you normally use.
Your chosen Filter Set will be home to
our new Visibility Filter. For example purposes I will use the Security Auditor View. Then select the Filters tab and click Create New Filter.
Use the values shown below, but feel free to adjust if needed, and then click Save:
At this point, you should be able to see the Uninitialized Variable findings in the High tab.
SPECIAL CONSIDERATIONS:
This change to the organization of your Fortify Findings right now, only is in effect for this one FPR. If you wish to have this filter rule exist in scan for other projects, then you will need to modify the default fortify filters be creating something called a custom Fortify Issue Template. Check your fortify documentation to get more information on this.
If you try to upload this to SSC (Software Security Center) where you might want to perform some reporting, then the default Issue Template that lives on SSC will be used to sort and organize your scan's issues, when generating reports. If you wish for your new custom Fortify Issue Template to be used for reporting and organization withing the web UI, then you will need to override the default Issue Template on the SSC server with your new custom Issue Template. Again, see your documentation for more information on this.
Finally, there is a way to potentially create a custom Fortify Control Flow rule (which will need to be used, together in combination, with a suppression rule) that will make it possible to essentially reassign the priority metadata for your particular issue, but this is quite difficult.
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.