Prepared for API Meetup Tokyo #13 https://api-meetup.doorkeeper.jp/events/41135
昨今、APIアクセス認可のフレームワークとして "OAuth" 仕様を使うケースが一般的になっています。本セッションでは OAuth 適用のトレンドと今後について紹介します。
This document provides an overview and summary of a presentation about authentication and authorization for cloud native applications using Keycloak. The presentation introduces Keycloak as an open source identity and access management solution, discusses the importance of authentication and authorization, and describes how Keycloak can be used for authentication methods like single sign-on, social login, and multi-factor authentication as well as authorization standards like OAuth 2.0 and Financial-Grade API 1.0. It also covers Keycloak features that help secure cloud native environments and applications.
The document discusses the challenge of implementing scalable authorization and describes how to use Keycloak's authorization service to achieve it. Keycloak allows defining fine-grained authorization policies and centralizing authorization data, improving scalability. Combined with OPA and CockroachDB, Keycloak can also enhance performance and availability while maintaining a centralized approach. The document provides an overview of Keycloak's authorization capabilities and how they enable scalable and standards-based authorization.
The document describes a session from the KubeCon EU 2023 conference on Keycloak, an open-source identity and access management solution. It provides an overview of the session which was presented by Alexander Schwartz from Red Hat and Yuuichi Nakamura from Hitachi and demonstrated how Keycloak can be used to securely authenticate users to applications like Grafana. It also discusses Keycloak's support for advanced security specifications like FAPI and efforts by the FAPI-SIG working group to promote features needed for compliance.
This document discusses security considerations for API gateway aggregation. It proposes building an API gateway aggregator in front of existing API gateways to expose APIs outside a company while minimizing security risks and impact on existing services. It describes how the aggregator can implement OAuth 2.0 authorization with a centralized authorization server and token exchange to authorize external applications without complexifying authorization for internal services. Advanced use cases discussed include supporting the Financial-grade API security profile for highly sensitive data and implementing zero-trust networking.
This document discusses the differences between assertion-based access tokens and handle-based access tokens in OAuth 2.0. Assertion-based tokens are parsable tokens like JWTs that contain user and client information, while handle-based tokens are opaque references. Assertion-based tokens have advantages for performance and scalability but require cryptographic protection, while handle-based tokens require validation through the authorization server. The document then examines scenarios where handle-based tokens could cause problems, such as with multiple authorization servers, and outlines secure validation steps for assertion-based tokens.
Yoshiyuki Tabata from Hitachi presented on API specifications and tools that help engineers construct high-security API systems. He discussed standards like OAuth 2.0, OIDC, PKCE, and OAuth MTLS. Useful features for testing include decoding tokens to check validity, and calling authorization server endpoints to validate access control. Implementing these features in mock servers and clients allows engineers to efficiently test if high-security requirements are met before production.
The document discusses implementing security and availability requirements for a banking API system using open source software. It describes using the 3scale API management platform and Keycloak identity management software together to meet authentication, authorization, access control, availability, and standards compliance requirements. Patches were submitted to these open source projects to enhance their features and better support the banking use case.
This document discusses implementing a lightweight zero-trust network using the open source tools Keycloak and NGINX. It begins by explaining the transition from a traditional network security model with clear boundaries between public and private networks to a zero-trust model where security boundaries are defined individually for each service or pod. It then covers how to implement the underlying technologies of JWT validation, mutual TLS authentication, and OAuth MTLS using Keycloak as an authorization server and NGINX as an API gateway. Additional topics discussed include how to secure east-west internal traffic and resolve potential policy decision point chokepoints.
This document discusses identity provider mix-up attacks in OAuth and describes several patterns of these attacks. It also outlines various mitigations and which mitigations are effective against each attack pattern. Specifically, it covers attack patterns that occur before and after the authorization code is obtained, listing three patterns for the former and two for the latter. Finally, it analyzes how the mitigation of using distinct redirect URIs matches up against each combination of attack patterns.
10/5(火)にNode-RED User Group Japan主催で開催された勉強会 「Node-RED UG Hacktoberfest 2021 説明会」での発表スライドです。
- 動画: https://youtu.be/dl_4MxT94l0
- 勉強会サイト: https://node-red.connpass.com/event/223770/
IoT Devices Compliant with JC-STAR Using Linux as a Container OSTomohiro Saneyoshi
?
Security requirements for IoT devices are becoming more defined, as seen with the EU Cyber Resilience Act and Japan’s JC-STAR.
It's common for IoT devices to run Linux as their operating system. However, adopting general-purpose Linux distributions like Ubuntu or Debian, or Yocto-based Linux, presents certain difficulties. This article outlines those difficulties.
It also, it highlights the security benefits of using a Linux-based container OS and explains how to adopt it with JC-STAR, using the "Armadillo Base OS" as an example.
Feb.25.2025@JAWS-UG IoT
9. 8
? Hitachi, Ltd. 2022. All rights reserved.
ステップアップ認証の設定方法 (1/3)
? Keycloakの設定方法
① ステップアップ認証用の認証フロー定義を作成する
② ACRとLoAのマッピングを作成する
ACR: 認証方法を区別するための識別子。OIDCに定義されている。
LoA: 認証のレベル(Level of Authentication)を表す数値。Keycloak内部で認証のレベル
の上下を比較するために使われる。
※基本的に両方ともレルム単位で設定する。クライアント単位での設定上書きも可能。
10. 9
? Hitachi, Ltd. 2022. All rights reserved.
ステップアップ認証の設定方法 (2/3)
? Keycloakの設定方法
① ステップアップ認証用の認証フロー定義を作成する
LoAが1の場合、
パスワード認証をする。
LoAが2の場合、
パスワード認証と
OTP認証をする。
11. 10
? Hitachi, Ltd. 2022. All rights reserved.
ステップアップ認証の設定方法 (3/3)
? Keycloakの設定方法
② ACRとLoAのマッピングを作成する
ACR: silver = LoA: 1
ACR: gold = LoA: 2
19. 18
? Hitachi, Ltd. 2022. All rights reserved.
(デモ)
ステップアップ認証の流れを実際に見てみよう!
20. 19
? Hitachi, Ltd. 2022. All rights reserved.
まとめ
- 新書籍「実践 Keycloak ―OpenID Connect、OAuth 2.0を利用したモダンアプリ
ケーションのセキュリティー保護」をご紹介しました。
https://www.amazon.co.jp/dp/4814400098
- Keycloakを使ったステップアップ認証の方法をデモを交えてご紹介しました。
21. 20
? Hitachi, Ltd. 2022. All rights reserved.
Trademarks
? OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
? GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other
countries.
? Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.