I am using the following SOAP API to interact with rally:
https://rally1.rallydev.com/slm/webservice/1.40/RallyService
And I am using a Username/Password which expires every three months. I was wondering if there is any settings on user accounts in rally that could prevent it from expiring.
Thanks,
Varun
Unfortunately a password expiration policy is required for all Rally UserID's. This is a commonly-requested feature however, to allow for more relaxed policies for automation users. This idea:
Change password policy for single user account
On Rally Ideas corresponds to this feature request. I'd encourage for you and your teammates to vote on it to help raise visibility with Rally's product team.
Also - you may wish to explore porting your automation code to one of Rally's REST-based toolkits.
Versions 2.0 and higher of Rally's Webservices will not include SOAP-based services. While SOAP will continue to be available in Webservices 1.x for a full year following the soon-to-be released Webservices 2.0, customers requiring new/updated Rally functionality will find that updates are no longer available in SOAP starting with version 2.0.
Related
in my company we are using azure api management.
I'm reading the microsoft doc and i'm focused on product and subscription. On 2 api i started to apply the product with related subscription (that i passed to my dev colleagues and they are using with our mobile app). On 99% of api we implemented jwt validation policy as security layer.
One or two api are exposed without subscription or jwt validations, as dev requirement.
I don't understand the subscription and their use. I would like to generate a subscription key specific for api without jwt policy, but i think is not the right way becouse the key will be hardcoded into our mobile app and can easily stolen i think.
here policy jwt:
<validate-jwt header-name="Auth-token" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized" clock-skew="600">
<issuer-signing-keys>
<key certificate-id="jwt" />
</issuer-signing-keys>
</validate-jwt>
There are some other method on api management to implement for this case? Or subscription is enough?
As you said the subscription key will be hard coded and you also have manually rotate it .
Jwt with bearer tokens are a better way because the tokens have expiration dates this makes them better.
Azure active directory is also good if you want RBAC.
Refer the following documentation for further details.
Well, I have an angular.js client and a WebApi Server. I want to use OAuth 2.0 authorization of Microsoft and I just can't understand how I should get the answer from the http get request to the /authorize endpoint and why when I try to make the request I get a CORS problem?
Check Authorize access to web applications using OAuth 2.0 and Azure Active Directory. It worked for me along with simple-oauth library.
Make sure that you totally understand what exactly authorization endpoind you need. I've started with Oauth 2.0, but then I realized that new v2.0 endpoint is better way for me with this tutorial for angular and workflow explanation:
In the past, an app developer who wanted to support both Microsoft
accounts and Azure Active Directory was required to integrate with two
separate systems. We've now introduced a new authentication API
version that enables you to sign in users in with both types of
accounts using the Azure AD system. This converged authentication
system is known as the v2.0 endpoint. With the v2.0 endpoint, one
simple integration allows you to reach an audience that spans millions
of users with both personal and work/school accounts.
And keep in mind that Live APIs are deprecated:
The Live Connect APIs are deprecated. We recommend that you use the
Outlook REST APIs to build your solutions. This will extend your reach
to Outlook.com users and Office 365 enterprise customers. Although the
Live Connect APIs will be supported in Outlook.com for the short term,
existing Live Connect API solutions might stop working without
advanced notice. If your app is using IMAP with OAuth 2.0, it will
continue to work, but our REST APIs are the primary APIs for building
apps that connect to Outlook.com and Office 365. Read the article on
how you can take advantage of the Outlook REST APIs.
I'm currently building an integration with Greenhouse.io's ingestion API which authenticates via OAuth 2.0.
In my database, I have a collection for both users and companies where multiple users belong to one company. I want to easily allow any user associated with a company to authenticate via OAuth to the Greenhouse API, allowing any user across the company to access the API.
My assumption is that I will need to somehow authenticate with OAuth and then store the keys in the customer document as opposed to the user document. How would I go about doing this with Meteor 1.3?
I'm using
Meteor 1.3
Blaze / spacebars for the frontend.
Thanks :-)
It's strange to me there isn't an obvious way to do this in Meteor. I found a discussion here with links to various projects to achieve this functionality: https://github.com/meteor/meteor/pull/1133
Could you help me determine which authentication protocol I should use for the following use case? I am new to this area of development and am a little bamboozled with all the technical information out there - so a 'for dummies' answer would be greatly appreciated.
I have an online learning website that hosts courses in English Language. A requirement has arisen that we should integrate with 3rd party Enterprise Systems (because we sell the courses to Enterprises).
The primary requirement is to allow 3rd party systems to redirect their users to my site and have them access it with there 3rd party system credentials (I believe this is called Single Sign-on?). The 3rd Party systems are obviously remote systems and I am focusing more on capability than 1 specific customer / integration.
So, what I am trying to understand, is what capability should I offer to allow this to happen? I am trying to develop a generic 'developer toolkit' so that I don't have to be bogged down in lots of individual integrations as and when they arise.
I have read that there are lots of protocols / things in this space (SAML, OAuth, OAuth2, OpenID, Shibboleth, etc) - so I wondered where I should focus my attention and research? Which is the most common among Enterprise systems (CRMs, etc)?
Also, as a sub-question. Is OAuth deprecated or sneered upon now that OAuth 2.0 is released?
Any help is truly appreciated!
Thanks all.
SAML 2.0 is the most popular protocol for Single Sign On when it comes to Enterprise systems. Most if not all enterprises are able to provide SAML based SSO for third party websites.
Ideally, if correctly implemented the enterprise would need to configure their system to send your website SAML assertions (Identity information in the form of XML) and you would the information in the assertion to log the user in.
The Enterprise would be called the Identity Provider (IDP) in this case and your website would be called the Service Provider (SP)
There are a number of open source libraries available that allow implementing SAML (Spring etc.), alternatively your existing servers may have the capability as well.
Once you have the base implementation done, you can then choose to do two things:
If the user does not exist in your DB, create a new record and allow the user access.
The enterprise that you are integrating with must supply a list of users before hand and then you can allow only the users that are present in the DB.
Although the second option has a lot of overhead and not used very often.
---------------------------- Answer to Comments-------------------------
It depends on the way you would setup the interaction.. There are two ways to setup SAML SSO:
SP initiated SSO: This means that the users always access your site and then is redirected to the IDP for authentication. The SAML token is sent back to your site post authentication.
IDP initiated SSO: This works in a way that the IDP generates a SAML token and directly posts it to the SAML endpoint of your website.
If you are using option#1 and users are already logged in step C would not be needed since the user is already logged in and the token can be directly generated.
For option#2 only the steps D and E would be needed. I would however urge you to strongly to not omit the SP Initiated SSO implementation since some IDPs do not support IDP initiated SSO.
Hope this helps
Avi
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.