I am trying to get Jira Cloud to integrate with my Gluu server for SSO. Everything I have read requires a metadata file from my SP. Jira does not provide that when setting up SAML. They provide SP Entity ID and SP Assertion Consumer Service URL. Does anyone have an example of their Jira metadata file? I asked Atlassian but I havent heard anything from them yet.
You can actually form your own metadata file if you have the correct parameters (which it looks like you have).
There is a tool here you can use to pass in those parameters and it'll produce the metadata XML. (Metadata is just a structured way of communicating the SP properties).
https://www.samltool.com/sp_metadata.php
Related
I need to set an influxdb 2.0.3 to be able to write data into it with a defined set of user/pass or token.
My use case is to provide a software component before deploy influxdb, and this component need to have a predefined configuration to write into influxdb (is not possible to interact with api influxdb, just write operation is implemented).
I'm understand in documentation that a user/password is couldn' be used with this new release to write data, only token provide this feature. Is it true?
In other hand, a solution is to set manually a predefined token into influxdb, but I don't found this feature in a api / documentation.
Someone have another solution or a way to bypass this limitation?
Thanks
You cannot define a token's string when creating one in InfluxDB. You will need to create one when you deploy it, and pass the newly created token to whatever software will be writing to InfluxDB.
I’m trying to integrate a third-party tool with Jira server via REST API.
Currently we have a customized Jira used by our client with a business specific issue types.
Basically all I need is to be able to create an issue of a given type, get response (success/error) and get metadata (list of required and optional fields) for that tool via REST API.
We have a create issue page on WebUI, where user can submit his request.
But the problem is all validation logic is “smashed” between some Javascript code, Behaviours and SIL Programs Manager add-ons, AJS scripts, Jira native fields configuration etc.
So I can’t use “plain” Jira REST API directly because it creates issues without taking in account business rules of a given issue type - e.g. requires fields, one fields can have values depending on another field’s value, an attachment is a required as part of an issue etc.
My question is what is the best way to make an integration with Jira.
I want to be sure if someone will try to create an issue via REST API, the data is consistent according to the issue business rules.
I was thinking to write some "proxy" REST API, which will do the all validation needed and create (or edit) / reject the request.
We've developed a separate Jira plugin which serves some scenarios. So, I can add those API to the plugin.
Or, use Jira REST API endpoints like POST /issue (and PUT /issue/), and I have to define a new screen for it, set all required fields via standard Jira settings, set Cascading fields rules and the standard validator will check if everything is ok out-of-the box?
Sorry, I’m new to Jira and not sure if my current understanding is correct now.
Thanks
Tricky. Best to validate the data in a single place (with one set of code) before calling the create REST API. That way you can also modify the validation logic more easily over time. I think I would probably define a new REST endpoint. ScriptRunner lets you script that nowadays
I've question regarding automation with oAuth 1.0a. I need to access a REST API at a oAuth provider on behalf of a user. The provider has oAuth version 1.0a implemented.
At forehand excuse my ignorance on oAuth, it's new territory for me.
I'm working on a .NET MVC 5 project and installed the NuGet Package as follows: "Install-Package DotNetOpenAuth.OAuth.Consumer". This installed the following:
Attempting to gather dependencies information for package 'DotNetOpenAuth.OAuth.Consumer.4.3.4.13329' with respect to project 'projectname', targeting '.NETFramework,Version=v4.6.1'... successfully installed dependencies and the DotNetOpenAuth consumer package.
My goal is to access a REST API when triggered by an external source which is not human. In short, a controller is triggered by an external process and sends data to my application. Next, I will need to access the REST API of the provider in order to process the received data. So, no human eyes or hands are available to login or copy a verifier of some sort.
I've been looking around, read about oAuth and the DNOA library. I kinda found that I have to obtain a RequestToken to start off with. I'm using the following code to achieve this:
InMemoryTokenManager tm = new InMemoryTokenManager("**consumerkey**", "**secret**");
var serviceProvider = GetServiceDescription();
var consumer = new DesktopConsumer(serviceProvider, tm);
string reqToken;
consumer.RequestUserAuthorization(null, null, out reqToken);
I read about the InMemoryTokenManager, ServiceProviderDescription, DesktopConsumer and that is pretty clear to me. Although I'm not surefooted about using DesktopConsumer instead of WebConsumer..
Now, I need to get a verification code from the Provider. But how to proceed next in order to get it?
I've looked at the UserAuthorizationResponse object which contains a property exactly for this purpose but I'm unable to figure out how to retrieve this.
With the request token and verification code I should be able to get a AuthorizedTokenResponse object and perform the REST API calls.
Can anyone help me out on this?
We have read the OKTA guides, but have two unresolved questions:
does OKTA support Artifact binding https://en.wikipedia.org/wiki/SAML_2.0#HTTP_Artifact_Binding
does OKTA/SAML 2.0 support unsolicited Identity Provider (IdP) artifact binding, or is it mandatory to have to be redirected from the Service Provider (SP)?
Regarding the first question
We face a situation where a large quantity of data would have to be transmitted through the user agent, and we are also motivated by security best-practice. Our opinion is that artifact binding is the best security model for SAML 2.0; and will also help reduce load on the user agent. Can OKTA support artifact binding? We haven't been able to find either a positive or negative confirmation in the documentation. Many apologies if this is an oversight on our part.
Regarding the second question
The problem we are solving is that we are integrating with an organisation who have a portal of products they recommend and for which they have organised access via their portal. Each of these products require authentication, making a good case for Single Sign On (SSO). Both sides of the integration would like the user experience to be: click on the link and be logged in to the service. This is different to most of the models for any SAML 2.0 modes of working as the workflow starts at the IdP rather than the SP. Is this possible in OKTA, or at all in SAML 2.0? Again, many apologies if we have missed this in the documentation.
Check the metadata generated by Okta. If it supports the artifact binding for messages sent to the SP, there will be an ArtifactResolutionService listed in the metadata.
The SAML2 standard supports unsolicited artifact binding. I don't know if Okta does however.
Doesn't seem that Okta supports this when I check the metadata.
Wikipedia shows what the ArtifactResolutionService item would look like in the metadata:
<md:IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo>...</ds:KeyInfo>
</md:KeyDescriptor>
<md:ArtifactResolutionService isDefault="true" index="0"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://idp.example.org/SAML2/ArtifactResolution"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
<md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idp.example.org/SAML2/SSO/Redirect"/>
<md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://idp.example.org/SAML2/SSO/POST"/>
<md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://idp.example.org/SAML2/Artifact"/>
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
<saml:AttributeValue>member</saml:AttributeValue>
<saml:AttributeValue>student</saml:AttributeValue>
<saml:AttributeValue>faculty</saml:AttributeValue>
<saml:AttributeValue>employee</saml:AttributeValue>
<saml:AttributeValue>staff</saml:AttributeValue>
</saml:Attribute>
</md:IDPSSODescriptor>
I've looked through Okta's configuration and can't find anyway to enable this so it shows up as an available service.
I am trying to get a SAML 2.0 token from an ADFS 2.0 ws-trust service using C#. The popular sample is this one http://leastprivilege.com/2012/11/16/wcf-and-identity-in-net-4-5-external-authentication-with-ws-trust/. However, this sample uses a UserNameWSTrustBinding which, according to this article http://msdn.microsoft.com/en-us/library/jj157091.aspx, did not make the jump to the System.IdentityModel namespace for 4.5.
I have been experimenting with this sample and some variants that I have found, but so far, the only results that I can get are a variety of error messages. I am wondering if there is any good way to debug the latest one, "The request for security token has invalid or malformed elements.". I turned on WCF logging on and determined that this message is being returned as a fault by the ADFS service.
Reviewing the AD FS 2.0/Admin events on the ADFS server, there is no indication of an error. Several posts indicate that this is common in an ADFS farm environment, but mine is a simple single server configuration.
Does anyone have a good way to diagnose this? Or, is there a good sample that comes with any configuration requirements on the ADFS server side?
This link http://social.msdn.microsoft.com/Forums/en/Geneva/thread/33fc091b-505c-481c-a61c-a8541a5ccf23 shows how to enable WCF and WIF tracing for the server side of ADFS 2.0. Modify the config file at C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config. (Change the three switchValue settings to Verbose and modify the trace listeners.) While following the instructions, make sure to change the types on the listeners. Something like
<add name="ADFSWifListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\adfs1.svclog" />
I also had to grant "Everyone" full access to the C:\Logs folder, you can refine those permissions with auditing if you like. Once the .svclog files have been created, they can be viewed with SvcTraceViewer.exe in %ProgramFiles%/Microsoft SDKs/Windows/v8.0A/bin/NETFX 4.0 Tools (or any other SDK version probably).
NOTE: Microsoft will not support the notion of logging trace data directly to a file, so you will want to turn this off or configure according to this article http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(WS.10).aspx for a production deployment.