What is Policy from ABAC Standpoint?
Policy is a set of rules that can be applied to specific API product to ensure only desired access is allowed for a specific consumer request.
You can set a policy with the attributes (properties) of the subject, object or action instead of themselves (the string) to control the access.
Why is Policy needed for ABAC?
What is user from ABAC Standpoint?
Users are part of organization and application. Admin can add in user and grant access to users to create/manage/view ABAC policies.
Why is application needed for ABAC?
User will create/view/Modify ABAC policies that are specific to application/organization.
Users with admin access can set policy rules at application level to control consumer access for specific attributes.
How to manage Users using ABAC UI?
What is application from ABAC Standpoint?
Application is nothing but API product that is available on Portal for consumer use.
Why is application needed for ABAC?
What is Organization from ABAC Standpoint?
Organization is a group that
Why is Organization needed for ABAC?
Tech
This blog describes the API versioning strategy and guidance of Anywhere APIs for publishers on how to implement it for their API products.
Semantic Versioning
API version numbers are in the format major.minor. Example, 3.12, where 3 is the major version and 12 is the minor version.
• A major version indicates a breaking (to the consumer) change from the previous major version, for example, removal of a field from the entity schema.
Anywhere Applications can use API-M ABAC solution to easily enforce attribute based control authorizations using this enterprise offering. This blog talk about Anywhere’s ABAC Implementation and how applications can take advantage of this solution and protect data from un-authorized users and actions.
What is ABAC?
APIM ABAC Enterprise Implementation Details
APIM ABAC - Sample Use Case
Request is intercepted by API-M (Apigee), which makes a call to Okta to find out the employee Type of the user.
Details: The AMS application success criteria has these conditions
Delete: employeeType is Pending_SA;
Update: employeeType either Pending_SA or Agent;
Create: employeeType is Pending_SA
After the required parameters are checked, an authorization request is sent to the ABAC auth engine along with the required parameters of subject, object, action, and other parameters like application and organization.
The AUTH Engine evaluates the relevant policies based on logical operators, for the defined subject, object, action, application (AMS)
Interested in implementing ABAC for your application or use case?
Its really simple and straighforward !! Here is what we need from you to implement ABAC for your application/use case.
Understand your application usage pattern
Provide us Consumer usage patterns
Where APIM should permit/deny the consumer requests e.g. What consumer can read/can not read,
Any datapoint that can be used to permit/deny access etc.
Work with Anywhere API-M team to implement the ABAC rules and set up policies
Tech
View your list of existing apps for a specific company or team here, My Apps - API Credentials along with the API credentials for an app. Here you see the API key and Okta credentials to access an API product. You can manage your existing apps on this My Apps Page.
Tech
The Manage Companies/Teams page allows you to create and manage companies, assign users as Company Admins or Developers, configure their roles and permissions, create and manage apps for accessing Anywhere products, and exit from companies when needed.
In 2006, Amazon Web Services (AWS), a small subsidiary of the online retail company Amazon launched Simple Storage Service (S3), its first public cloud service. Later that year, it added Simple Query Service (SQS) and Elastic Compute Cloud (EC2) to its portfolio of offerings, kicking off a technological revolution.1 It has been over 15 years since those first AWS services changed the landscape of computer infrastructure, and many more years since the creation of the foundational technologies and ideas that those services were built on. Cloud computing is no longer the future of technology. It is the present and any organization that has not embraced cloud is living in the past. There is a huge leap, however, from accepting cloud as the right direction to being a cloud-proficient technology enterprise. Cloud computing represents such a fundamental change in technology mindset that any organization that wasn’t “born in the cloud”, and in particular large, well established enterprise organizations, will face significant challenges on their cloud journey. How to get started building a cloud technology culture is the main goal of the Cloud First strategy, a strategy that is a key pillar of Anywhere’s overall enterprise cloud strategy.
By definition, Cloud First simply means prioritizing cloud solutions over non-cloud solutions in all cases within an organization. This means every decision should move the organization more towards the cloud and any decision that does not do so should be treated as an exception and needs to be justified. Essentially, if there is a cloud way to do something, that’s the way it should be done. Cloud First gives us a key to make good decisions that support our cloud journey, and this is a powerful tool in driving cloud adoption. It may seem simple, but putting this into practice can be challenging. Some decisions that seem to have nothing to do with cloud are actually cloud decisions in disguise. Cloud solutions may be more difficult and costly than non-cloud solutions, especially early in a cloud journey, which can deter Cloud First. Cloud First requires broad commitment across the enterprise and steadfast resolve by each individual to live life Cloud First.
There are many obvious cloud vs. non-cloud decisions:
Q: Where will we host this new app? A: In the cloud, of course!
Q: Should we choose the SaaS solution or the COTS solution? A: Choose the SaaS solution, of course!
Q: What technical debt should we target this quarter? A: Focus on building cloud maturity, of course!
Questions like these are easily answered by Cloud First. However, there are many technology decisions made every day in any enterprise organization that may not be clearly cloud vs. non-cloud decisions. Indeed, some decisions about technology are made without even realizing they are technology decisions, like when delivery timelines are set without adequate input from technology teams. Such timelines can preemptively restrict technology options, potentially making a cloud vs. non-cloud decision before anyone realizes it. There are many other decisions that may not be immediately obvious as cloud decisions:
Are we designing products in a way to optimally leverage the capabilities of the cloud?
Do our organizational changes help us in our journey to cloud?
Are we making cloud a priority in hiring and other staffing decisions?
Are we Cloud First in our training opportunities and development goals?
Are we selecting contractors that enable our cloud journey or ideally are Cloud First themselves?
Because so many decisions are potentially cloud vs. non-cloud decisions within an enterprise, it isn’t enough that only the technology team be Cloud First. To some degree, the whole enterprise needs to understand and embrace Cloud First and be able to apply it to strategic decisions.
The other major challenge in adopting Cloud First in a large, well established enterprise that runs on legacy technology is that cloud solutions will often be more difficult and costly than non-cloud solutions early on in the cloud journey. Building out a cloud platform takes time and resources that could be directed elsewhere. Deploying the first greenfield apps to cloud may require skills and processes that don’t yet exist in an organization which can be slow and expensive to develop. Migrating legacy apps to cloud effectively requires rearchitecting and replatforming that can take away from delivering business value for some time. These things and more can make Cloud First initially seem like an expensive strategy with little value add. It is critical for everyone to remember these things will pass as cloud maturity is gained and eventually the organization will end up in a better place. Don’t let the daunting cost and challenge of early cloud projects deter you from living your life Cloud First.
“Once you start down the non-cloud path, forever will it dominate your destiny.” - Master Yoda
Cloud First is an organizational strategy, but it takes commitment at the individual level to make any cloud transformation successful. So how can you personally live your life cloud first?
Whenever you have to choose between a cloud solution and a non-cloud solution, choose the cloud solution. Consider whether or not a choice is actually a cloud decision in disguise and don’t let cost drive you to make a non-cloud decision.
Become a cloud expert! Cloud First is not about alienating people without cloud experience, rather it is about empowering people to develop new skills or augment exiting ones with new cloud knowledge. We must invest in training to be truly Cloud First, take advantage of that!
Become a cloud evangelist! Tell your family, friends, dogs, neighbors and especially your peers at Anywhere about the cool thing you did in the cloud or the cloud certification you just achieved. Success breeds believers and Cloud First depends on buy-in from the whole team.
Reach out to the Cloud COE with any questions about cloud or if you’d like to get more involved.
Cloud is The Way, but realizing the true value of the cloud can be difficult for any enterprise. Cloud First gives us direction and is a critical tool to drive our cloud journey, but ultimately it is only one piece of a holistic enterprise cloud strategy. Once we make the decision to go to cloud, myriad decisions await and broader guidance is needed to navigate the potential pitfalls they bring. However, if we can take that most important first step of committing to cloud and living our lives Cloud First, we will be well on our way to realizing all the benefits that cloud can bring.
Travis Williams is a Director of Enterprise Architecture at Anywhere and a cloud and security expert. He has been a part of cloud transformations at many enterprise organizations, some successful and some not so much, but each one a great example of why culture change is the most important part of cloud adoption.
Tech
Once you get API credentials for a specific product, you will need to generate bearer token for accessing the APIs. Please find below the steps for the same.
Step #1 Download Postman Collection
If you do not have the postman tool installed, refer to download instructions and install Postman.
Step #2 Get API product credentials for token generation