It is likely that IDPro members are grappling with providing identity and access management services to a newer type of identity in the enterprise that is not a human, is not purely functional and not always privileged, and may have traits that apply to all – bots. Bots can duplicate human interaction with applications or automate tasks or end-to-end business processes traditionally done by humans. Bot identities need to be available for use by robotic process automation (RPA) software, where the intelligence about the functions the bot’s accounts are performing typically lives. Thus, the bot’s core identity must exist in identity management systems so that bot access is created, reviewed and controlled much like any other worker’s access.

For this article’s purpose, a bot is simply an identity with linked accounts used by software. A bot’s Active Directory account may look a lot like a human’s Active Directory account. Some bots may be deployed with ramped-up functional accounts performing the same maintenance type tasks repetitively on many like-systems – they have a confined scope. Other bots may perform end to end business processes and require the same authentication and authorization services as a human worker to function. Service management platforms need to be able to find bot identity data so that resources can be requested and approved for the bots. Termination, deletion, transfer, certification, separation of duties checks, adequate audit trails, privileged access management, monitoring and a host of other services within the enterprise apply. Each of these services may already exist in an organization for human identities and only need tweaks to make them work well for bot identities. As an example, an inaccurately timed access disablement for a human worker may cause far less organizational stress than an unwarranted access disablement for a bot. A bot owner may have many bots that collectively pose a separation of duties problem for the owner that is more difficult to detect. Identity Governance and Administration (IGA) architectures must evolve quickly to encompass bot identity so that organizations can more safely take full advantage of the new capabilities at their disposal.

The following is a brief list of suggestions for developing basic bot identity capabilities:

• Engage the appropriate teams in discussions about governance and to review access control procedures, audit and compliance requirements, privileged access management requirements, password vaulting, etc. Update cyber policies and standards to include bot identities.
• Recognize bots as a new identity type because it is important to differentiate bots from the rest of the worker population. Being able to identify different populations of nonhuman identities and accounts in the identity data allows the use of those population indicators to determine where the account data should exist and which controls to apply.
• The new worker type should be used to ensure that bots do not automatically pop up in systems, applications, org charts and reports that apply only to people, with unfortunate side effects; bots do not need compliance training, to enter timesheets, get paid or have access to benefit plans. Therefore:
  • Have data consumers opt-in to bot data that may be available in data warehouses or other systems that provide data to the organization. Data consumers must make a conscious decision to subscribe to bot identity data if they require it.
• Develop a system or leverage an existing system from which to source bot identities using the new identity type; define a baseline bot identity profile that works for your organization. Use your identity management systems to manage bot account access. (Using bots to manage identity management systems and functions is a fascinating but different topic.)
• Map the bot profile to the user account schema on your major systems and applications. Decide what those account profiles will look like.
• Apply a unique identifier to each bot in enterprises that use a unique identifier for each human identity, to simplify the application of existing identity management and other business processes to bots.
• Create a bot request process in the service management system and enforce consistency in the bot request and onboarding process.
• Tie each bot identity to an approved RPA program as prerequisite to the bot identity creation request. Just as governance and accountability should apply to an RPA program, governance and accountability must apply to the bots that serve them. Wrapping the bot creation process within an already approved bot program adds a layer of oversight and a place to go when follow up on a bot account is needed.
• Tie each bot identity to an owner \ manager during the bot identity creation process; the frontline person accountable for the bot’s existence and access. Have the manager, and a representative of the RPA program the bot is working for, each approve the bot identity’s creation as an added measure of bot population control.
• Add automation to manager changes so that if the manager transfers or leaves the organization a new manager is automatically assigned to the bot.
• Maintain the audit trail including the multiple approvals for bot creation and access. Any additional access provided to the bot also needs inclusion in the audit trail. Going forward, the activity of the bot should be monitored, especially where privileged access is concerned.
• Additional privileged access controls that are applied to people performing privileged access tasks should also apply to bots performing the same privileged functions.
• Certification of bot access and functionality on a schedule appropriate to the functions it performs should be included in the lifecycle.
• Develop an offboarding housekeeping plan to disable and eliminate bot accounts that are no longer needed.

The post Bot Identity appeared first on IDPro.

• Difficulty finding someone with solid technical experience
• Location strategies narrow down the already small number of qualified applications
• Salary requirements can be out of reach for companies
• Factor in the need for niche skills – vendor specific expertise, new and emerging technology, or even support for legacy technology.

I could continue this list, but to put it simply, everyone who is recruiting is looking for the same type of Identity and Access Management unicorn that you are.

So, what do you do?

Train your own Identity & Access Management Engineer!

Organizations can be successful in reskilling internal talent to fill technical IAM roles if the following criteria are met in partnership between the employee and employer:

• Recognize interest and value for both the employee and the company
• Successfully navigate information paralysis
• Successfully manage setbacks and challenges

Recognizing Interest & Value

Both the company and the employee should benefit from training an engineer on the job. The company benefits by retaining a fantastic worker (let’s be honest, if you weren’t fantastic, you likely wouldn’t have this opportunity), and they save up to 12 weeks of resource time, if not more, by avoiding the onboarding of a person new to the company. The company also saves time and money in recruiting for these hard to fill roles.

You’re likely wondering, how you recognize interest or value in this move for yourself. The answers to the questions listed below were crucial to my success as I trained, on the job, to become an Identity Engineer at Thomson Reuters.

• What position do you want to be in 2 or 3 jobs from now? Or 5 years from now?
• Do you want to do more technical, strategy, or management type work?
• What skills or experiences do people in your goal position have, that you may need to develop further?
• What subjects, type of work, technical areas, or projects energize you in your current role?
• If you choose a broad area, such as Identity & Access Management, what specific area within IAM energizes you or makes you excited?

Pro tip: if you are unsure what area of IAM may be best for you, reach out to the IDPro Slack Channel community; it is filled with many folks across IAM who would be more than willing to share what they do with you.

Successfully Navigating Information Paralysis

Now that you have a goal position, opportunities for growth identified, and a technical area of focus, you’re ready for the next step. But, where exactly should you start?

Pro tip: Get ideas out of your head, keep a list of the subjects you should learn about and refer back to it often.

Have team members review a list of subject areas you have found as learning opportunities; this will give you a sanity check and also give them a chance to provide feedback in terms of priority. Then, have your manager review your learning list.

After your manager has reviewed your list, you’re ready to hit the ground running! But wait – where do you start? What resources do you use?

My recommendations for learning while on the job:

• Focus on no more than 2 information areas at one time
• Job shadow with colleagues
• Narrow down learning resources to what works best for you:
  • Books (IDPro’s Annotated Bibliography is a great place to start)
  • Online Training & Labs
  • Independent Research

Managing Challenges and Setbacks

I have learned a lot of lessons throughout my 18-month journey as an Identity Engineer. Here are a few pieces of advice I would recommend to anyone considering this journey:

• It will be difficult, don’t underestimate that, and don’t get down on yourself. I tend to want instant gratification; this is not the place for that (most days).
• Be patient, it is going to take time. See above.
• The practice of IAM was not built in a day, you’re not going to become an expert in a day.
• Develop a system that works for you in order to see progress. Turn your learning list into a checklist, aim for certifications or specific objectives with timelines to help you feel like you’re moving forward.
• Remember your strengths and continue to use them, you were given the opportunity to move to a more technical role for a reason. Your strengths still apply and add value to your team.

The journey of becoming an Identity Engineer is not an easy one, but it has tremendous value. If you are a manager of an IAM team, I encourage you to take the chance on an employee who is interested in engineering. This journey is just as valuable for you, as a leader, as it is for the worker.

For more detail on this topic, check out my Identiverse 2019 presentation:

How to Become an Identity Engineer: A First Hand Account of Becoming an Identity Engineer on the Job

Alyssa Kelber
Identity Engineer at Thomson Reuters

The post How to Train an Identity Engineer appeared first on IDPro.

As the use of the web evolves, the proliferation of attacks and the emergence of problematic practices (such as aggressive user tracking from ad platforms) is leading browser makers to introduce new measures to contain those issues. Unfortunately, some identity scenarios are getting caught in the crossfire: as browsers change the “laws of physics” on which protocols and practices rely, existing services and software components will need to adapt or lose their user’s ability to sign in and operate the applications relying on them.

In this article we will discuss one of the most impactful changes on the horizon, the way in which Chrome (and soon after, others) handles cookies in case the SameSite attribute is not set.

SameSite changes impact in a nutshell

Today’s identity flows rely on cookies for two main purposes:

1. Keeping track of some information across redirects, and tie it to a particular user agent instance (for example, the Nonce value in OpenID Connect).
2. Representing the existence of an authenticated session, typically by emitting a cookie in the domain of the authentication authority (authorization server, IdP depending on the protocol).

Those cookies are often used in cross site protocol legs, where requests go from the authority domain to the app’s, and vice versa.The correct outcome of those protocol exchanges depends on the presence of those cookies in the request.

The SameSite cookie attribute instructs the browser on the circumstances in which a cookie should or should not be sent alongside a request when the domain on which the request originated differs from the destination. SameSite is a relatively new attribute, hence many middlewares and identity providers are not aware of the attribute and therefore don’t set it. 

The problem this creates is that starting February 2020, Chrome will change the behavior for cookies that do not explicitly set the SameSite attribute. The new default behavior will be to NOT send cookies with all requests (i.e. the behavior of SameSite=Lax) causing some existing identity flows to malfunction.Firefox will be right behind.

The good news is that the Identirati have been on top of the problem for some time, and nearly every Identity Service Provider in the industry has a plan for guaranteeing business continuity. The bad news is that, if you own a web application leveraging one of the affected flows, you might need to update the identity SDKs to a version that knows how to handle the SameSite attribute.

In the following sections we’ll dig just deep enough to get affected scenarios and remediations in better focus. If you want more details, there’s a growing number of deep dives posts on the internet: we’ll list some relevant links at the end of this article.

SameSite Mechanics and New Default Browser Behavior

Let’s invest a few moments to learn more about SameSite goals and behavior in more detail.

We are all sadly familiar with the cross site request forgery (CSRF) class of attacks. The idea is that a malicious actor can somehow trick the user’s browser to hit a web app where they are authenticated (e.g. they have a session cookie for) and make it perform actions they don’t want, or aren’t aware of.

CSRF attacks are only possible because the malicious requests include session cookies, the artifacts proving that the user has a valid authenticated session. The idea behind SameSite is that by preventing the browser from sending cookies to a domain when a request is triggered from a different domain, the typical way in which CSRF attacks are conducted,  the entire class of attacks is mitigated.

The SameSite attribute provides cookie writers various options to dictate in what circumstances browsers should send or withhold cookies to a domain.

• SameSite=Strict determines that a browser will send a cookie for sampledomain.com only if it is already on a sampledomain.com page, or in other words if the request was triggered while the browser was already pointing at the target domain.
• SameSite=Lax will send cookies to sampledomain.com even if the request originated from anotherdomain.com, but only if the request was initiated by a user explicitly clicking a link to sampledomain.com.
• SameSite=None signals to the browser that it’s OK to send cookies to sampledomain.com regardless of how the request originated.

When faced with cookies without any SameSite value set, as of today browsers default to the behavior described so far for None. But as anticipated earlier, around February 2020 Chrome is scheduled to make changes. The new behavior is described in detail here – but in short:

• Cookies without a specified SameSite value will be treated as Lax
• Cookies with SameSite=None must also be marked as Secure (only travel over HTTPS) or will be blocked 

Google announced the intent to turn the new behavior on as default in 78 (beta) and Chrome 80 (stable), estimated to be released in February 2020. Firefox already added the behavior as opt in from version 69.

To complicate things: browsers in use today have different ways of reacting to cookies carrying the SameSite attribute, and are unlikely to be all updated to comply with the new behaviors. For example: browsers complying with the earliest SameSite definition will ignore (not send) cookies with any SameSite attribute value other than Lax or Strict, affecting cookies marked with SameSite=None; and WebKit based browsers on iOS version 12 and lower will erroneously interpret SameSite=None as SameSite=Strict. You can find a detailed list of those behaviors in <link>. 

This will complicate any remediation strategy we’ll have to apply to preserve identity functionality, forcing identity providers and SDKs to accommodate the different behaviors of multiple browsers- or purposefully forsaking support of some version.

Now that we have a better idea of how SameSite works and what changes are coming our way, we are better equipped to understand what exactly is likely to break in existing identity flows and what remediations are being considered across the identity industry.

Impact on Identity Flows and Remediations

Let’s go back to the two identity flows relying on cookies that were mentioning at the beginning of the article.

To expand on scenario 1, consider the particular instance of a web app implementing web sign on using OpenID Connect and the form_post response type. As part of crafting an authentication request in that style, the web site generated a nonce– a unique value that will be passed to the authorization server and that it is expected to be included, unchanged, in the resulting id_token proving that successful authentication occurred. The idea is that the web app will only accept id_tokens containing a nonce value it recognizes, thus preventing replay attacks. 

Here’s the relevant detail: web apps usually save the nonce value in a cookie, so that they can 1) tie to the session with a particular user agent and 2) remain stateless. Normally the cookie containing the nonce is sent to the web app together with the http POST containing the id_token, allowing the web app to perform the necessary comparisons. Today’s nonce cookies are mostly produced without any SameSite value: which means that with the changes described in Chrome 80, those cookies will be considered as SameSite=Lax, and given that the POST originates from the authorization server domain to the app domain, the browser won’t send the nonce cookie… causing the nonce comparison to fail, and the sign in operation to fail altogether.

What’s the solution here? The obvious approach is to modify the logic generating the nonce cookie, typically residing in a middleware or similar component, to carry SameSite=None. That will restore the ability of the browser to include that cookie in POSTs at sign in time.

One extra requirement here is that the nonce cookie must also be marked as Secure and sent over HTTPS, per the new Chrome rules for SameSite=None cookies. That might seem obvious to anyone familiar with how OpenID Connect and OAuth2 work, given that the use of bearer token makes it necessary to perform all communications over secure channels. However, many Identirati are often surprised when learning that applications are routinely hosted on HTTP during the development phase, and many developers aren’t all that familiar with setting up HTTPS. Although as providers we can develop new middlewares and SDKs that set SameSite=None for the nonce cookie, we cannot handle the HTTPS requirements on the developer’s behalf; that is likely to lead at least some developers to abandon standard based flows to less secure solutions, which is why it would be ideal to have browser vendors provide some constraint relaxation in development mode (say admitting SameSite=None on HTTP if the target host is localhost).

The older browsers and the WebKit versions afflicted by the bugs described earlier are also a problem, as their reaction to SameSite=None will be to omit the cookie in the request. Some providers are implementing complex user-agent detecting logic, aimed at determining whether the resulting cookie should include SameSite=None (newer browsers) or not (older browser). The current consensus from the identity community is to circumvent the problem by always emitting two cookies, one with SameSite=None and the other without, at least while the offending browsers aren’t fixed or are no longer supported. The approach isn’t issue-free (platforms generating large cookies are likely to exceed browser limits if they emit duplicates) but it is the best option to date, and the one officially recommended by Google.

The remediation discussed here is largely aimed at web apps and the SDKs/middlewares used to implement web sign on, and in particular the ones using form_post response type (the ones leveraging full page redirects and the authorization code flow for the same purpose aren’t affected).

Let’s also look at scenario 2 in which case an Identity Provider writes a cookie representing the user’s authenticated session and the application uses that cookie via an iframe to refresh the applications tokens. A key aspect of the SameSite processing rules is that cookies marked as SameSite=Lax are NOT sent when requests occur in iframes unless the domain main page and the iframe are the same which is NOT the case for the identity flow referenced above. This affects any Single Page App (amongst other scenarios) that may be using a hidden iframe with OpenID Connect prompt=none processing to refresh tokens within the app. At the time of this article, the only remediation is for the IDP to set the SameSite=None attribute on its authentication session cookies. This is less than ideal as it creates a security exposure for the IDP by allowing those cookies to be sent in 3rd party contexts, increasing the likelihood of CSRF attacks.

The Future

This is not the end of changes coming from browser vendors as can be seen by the Intelligent Tracking Protections initiated by Apple as implemented in Safari and other browsers. While ITP is focused and removing the ability of 3rd party advertisers from tracking users across the web, it can have unintended consequences for some Identity flows as well. Discussing these changes in detail is outside the scope of this article though we highly recommend reading through the additional information provided via the included links. Additionally, there are recommendations from the browser vendors to change the way browsers manage state via HTTP State Tokens and also thinking around how browsers can better manage a user’s signed-in state. These topics are also outside the scope of this article but additional links are provided.

Conclusion

If you’ve made it this far, thank you for reading through to the end! The final and primary recommendation is to review any identity related flows in your system to determine if they will be affected by the SameSite changes and make sure to take action before the February 2020 deadline.

Additional Information

Recent Presentations and Blog Posts

OpenID Foundation Workshop: Browser Changes impacting Identity Flows

Intelligent Tracking Protection

Web Tracking Prevention Policy

ITP 2.1

ITP 2.2

ITP 2.3

Browser Vendor Proposals

HTTP State Tokens

Managing SignedIn state in the Browser

Browser based “VPNs”

Combating Fingerprinting with a Privacy Budget

Vittorio Bertoccio

Principal Architect at Auth0

George Fletcher

Identity Architect at Verizon Media

The post SameSite: how upcoming browser changes will affect common identity scenarios appeared first on IDPro.