Development of FAPI (Financial API) Security Profile
by 乗松隆志 / NORIMATSU，TAKASHI
Hello.
We've been trying to use keycloak to protect API services provided by financial institutions.
Under governmental regulation (e.g. Payment Service Directive(PSD2) in Europe), high level security is required for financial sector. One of the most promising security standard for financial API services is Financial API(FAPI) of OpenID Foundation. This is still implementer’s draft, but banking API systems compliant to FAPI are being implemented in some countries.
We've investigated keycloak and found that keycloak does not meet some of FAPI Security Profile requirements. We've been engaging in realizing them in keycloak, but had a lot of works. Is there someone who is interested in it?
Also, I'm afraid that someone has already planned to support FAPI requirements and/or done some of them. Because it seems that there are some related JIRAs, please tell us the plan of related JIRAs(below 1) tickets).
We’ve created JIRA tickets to realize FAPI. Some tickets have already been resolved while others have been newly created.
Also advice of how to proceed is also welcomed.
1) Aggregated tickets
https://issues.jboss.org/browse/KEYCLOAK-6767
2) Related to existing tickets
* signed and encrypted ID Token
https://issues.jboss.org/browse/KEYCLOAK-6768
It seems that JWE has already been implemented and adopted to authorization code.
Is there any plan to realize signed and encrypted ID Token using this JWE libraries?
https://issues.jboss.org/browse/KEYCLOAK-5288
https://issues.jboss.org/browse/KEYCLOAK-5290
https://issues.jboss.org/browse/KEYCLOAK-5569
* Multi-factor authentication and its corresponding "acr" value in ID Token
https://issues.jboss.org/browse/KEYCLOAK-6769
There has already been some discussion on this issue, but not resolved.
Is there any plan to continue and resolve it?
https://issues.jboss.org/browse/KEYCLOAK-3314
2) Newly created
* JWS signatures using PS256 or ES256 algorithms for signing
https://issues.jboss.org/browse/KEYCLOAK-6770
We’ve investigate why FAPI excludes RS256 and found that RS256 (RSASSA-PKCSv1.5) seems to be considered not secure because several vulnerabilities have been reported.
There are a lot of points using JWS signature not only Access/Refresh/ID Token but Requesting Party Token, Permission Ticket, Request Object, Response from UserInfo Endpoint, JWS Client Assertion, JWT telling events to Clients using client adapter. But I think only it be adequate to target Access/Refresh/ID Token at this time.
However, I’m afraid that some of these points use hard-coded RS256 JWS signature so that it might be difficult to choose other signature algorithm like ES256.
As for signature algorithm, it might be easier to adapt PS256 than ES256 because PS256 is RSA based signature algorithm (RSASSA) like RS256 so that key pair representation is the same. Therefore, I think PS256 could share the same RSA key pair as RS256.
However, it seems that OpenJDK does not support PS256 (“SHA256withRSAandMGF1”).
Considering this point, ES256 (“SHA256withECDSA”) might be only viable option, but additional works like key management be needed comparing with PS256.
* Holder of Key mechanism: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
https://issues.jboss.org/browse/KEYCLOAK-6771
keycloak has already implemented treating X.509 Client Certificate in TLS session.
Also, keycloak has implemented JWS Client Assertion in private so that it has capability of managing X.509 Client Certificate.
It seems that these feature can be used to calculate X.509 Client Certificate thumbprint and embed it onto Access Token that can be used in Sender Constraint.
* State hash value (s_hash) to protect state parameter
https://issues.jboss.org/browse/KEYCLOAK-6700
PR was sent.
3) Resolved
* RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
https://issues.jboss.org/browse/KEYCLOAK-2604
* scope returned in the response from Token Endpoint
https://issues.jboss.org/browse/KEYCLOAK-5661
* OIDC Client Authentication by JWS Client Assertion in client_secret_jwt
https://issues.jboss.org/browse/KEYCLOAK-5811
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
6 years, 2 months
State hash value (s_hash) to protect state parameter (Related to FAPI)
by 乗松隆志 / NORIMATSU，TAKASHI
Hello.
Last year, I sent some PRs to meet Financial API(FAPI).
FAPI is API's security requirement for API services in financial sector.
It is specified by OpenID Foundation.
http://openid.net/wg/fapi/
FAPI seems to be promising for conforming to PSD2 (Payment Service Directive) in Europe as API Security Profile.
Past PRs (Issue:KEYCLOAK-5661, KEYCLOAK-2604, KEYCLOAK-5811) are related to FAPI Part1. Recently, I've investigated into keycloak to find out whether it conforms to Part 2 (Read and Write API Profile Requirements) for Authorization Server and found that it does not satisfy several points.
Therefore, I've implemented one of them, state hash value (s_hash) to protect state parameter in authorization request.
FAPI Part 2 Read and Write API Security Profile Requirements for Authorization Server is the following.
http://openid.net/specs/openid-financial-api-part-2.html#introduction
http://openid.net/specs/openid-financial-api-part-2.html#authorization-se...
* shall include state hash, s_hash, in the ID Token to protect the state value; is met by this PR.
https://github.com/keycloak/keycloak/pull/5022
Hope this PR is reviewed and merged.
And I am also working to meet other points of FAPI Part2, it may take several months (hopefully).
Best Regards
Takashi Norimatsu
Hitachi, Ltd.
6 years, 2 months
Re: [keycloak-dev] [keycloak-user] Authorization Services and UMA 2.0 changes
by Pedro Igor Silva
PR is being reviewed. It should be merged very soon.
On Thu, Feb 22, 2018 at 5:14 PM, Corentin Dupont <corentin.dupont(a)gmail.com>
wrote:
> Hi Pedro and all,
> how is it going with those changes? Any landing date in view?
> It looks very promising.
>
> On Mon, Jan 29, 2018 at 3:09 PM, Corentin Dupont <
> corentin.dupont(a)gmail.com> wrote:
>
>> That sounds great, thanks a lot!
>>
>> On Mon, Jan 22, 2018 at 2:07 PM, Pedro Igor Silva <psilva(a)redhat.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> We are about to finish the initial round of changes to make Keycloak
>>> Authorization Services compliant with UMA 2.0.
>>>
>>> One of the main changes is related with a new OAuth2 Grant Type
>>> introduced
>>> by UMA 2.0 [1] and how it will be used as a replacement for both
>>> Entitlement and Authorization API. In UMA 2.0, there is no Authorization
>>> API anymore, thus it will be removed on future versions of Keycloak.
>>> Regarding Entitlement API, it will also be removed in favor of the new
>>> grant type, but in this case we are using some extensions to UMA grant
>>> type
>>> to provide the same functionality. One of the objectives of this change
>>> in
>>> particular is to have a single endpoint from where permissions can be
>>> obtained.
>>>
>>> Another important change is also related with UMA where end-users should
>>> be
>>> able now to manage their own resource and permissions via Account
>>> Management Console. Users would be able to access a "Resource" page from
>>> where they can:
>>>
>>> * See the resources they own
>>> * Check for pending permission requests (waiting for the owners
>>> approval).
>>> As well options to grant/deny the request.
>>> * Check for all "shared resources" / granted permissions. As well options
>>> to revoke permissions
>>> * Select an user they want to grant access to a resource and/or scope
>>>
>>> Other changes are related with the Policy Enforcer, Authorization Client
>>> Java API and configuration. For these areas in particular changes are
>>> minimal, specially regarding policy enforcer configuration.
>>>
>>> These changes are targeted to Keycloak v4 and we'll be updating docs
>>> accordingly, specially on how to migrate to the new version.
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.
>>> 0-09.html
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
6 years, 2 months
Keycloak session expired event
by Jasper van Zuijlen
Hi all,
For our application we'd like to make use of the sessions managed by Keycloak. This has proved to work via a plugin up to the point where we want to know when the session ends. Is there any way of getting an event of the expiring of the user session from Keycloak? We'd rather not resort to querying Keycloak for this info from a separate program.
Thanks!
6 years, 2 months
Scope parameter support
by Marek Posolda
Hi,
started looking at OAuth Scope parameter support. Wanted to clarify some
things before start implementing:
- Client Scope will allow to group protocolMappers and Role Scope
Mappings. Pretty similar to current Client Template
- Do we want to get rid of "Client templates" entirely and rename them
to "Client Scopes" ? Or introduce Client scopes as separate thing in
addition to client templates? My vote is to rename and get rid of client
templates. It would mean get rid of new option "Login theme" from client
template (client scope) then? As otherwise is unclear from which Client
Scope will client inherit it (assuming client can be inherit from
multiple Client Scopes, not just from single Client Template like is now).
- Client can inherit from more Client Scopes. I can see 2 groups:
-- Default Client Scopes - Those will be applied even if not requested
by OIDC scope parameter
-- Optional Client Scopes - Those will be applied just if requested by
OIDC scope parameter
- Do we still want to keep ProtocolMappers per client and
Role-Scope-Mappings per client? I can imagine we get rid of them and let
them to be completely inherited from "Client Scopes" . My vote is yes.
Just afraid if there are some issues with it like:
-- backwards compatibility and migration -- But hope that's manageable
-- Option "Full Scope Allowed" from role scope mappings -- but that
should be solvable too (See below)
- Consent screen:
-- Currently we have set of protocolMappers and set of roles on consent
screen. I assume we want to get rid of this and have just single thing:
Set of client scopes. Correct?
-- If yes, how to proceed with the protocolMappers and Role Scope
Mappings, which are defined directly on the client? If we get rid of
them (as I mentioned above), we don't have this issue. If we don't get
rid of them, we can have something like "Default consent", which
encapsulates all the protocolMappers and Role Scope Mappings declared
directly on client. WDYT?
- Option "Is Consent Required" and "COnsent Text" on protocol mappers -
Do we want to remove those? I think yes.
- Option "Full Scope Allowed" on clients and option "Scope Param
Required" on roles.
-- I can imagine we remove both and replace them by having special
builtin Client Scope, which will automatically have all the roles (all
realm roles and all client roles of all clients) added to itself.
-- When new client is created, it will automatically have this builtin
Client Scope added to itself - because currently newly created clients
also have "Full Scope Allowed" ON by default.
-- When new role is created, it will be automatically added to that
builtin Client Scope.
-- Admin has ability to remove the roles from this Client Scope. This
defacto has same meaning like previously "Scope Param Required" flag on
role, which is curently used for "offline_acces" role.
- I was thinking about creating some UI in admin console for "Scope
Evaluating" . Admin will see effective roles and effective
protocolMappers based on "scope" parameter he provides. I guess this
doesn't have so big priority, but will be good to have IMO.
- UserConsentModel - do we remove roles and protocolMappers and replace
them instead with Client Scopes? I think yes. Also change the
"Applications" tab in account management accordingly and have the same
"Client Scopes" like those, which were displayed on consent screen.
- Tokens - I think we still want to keep "Effective" claims and
"effective" roles in tokens as is now? At least in first iteration.
WDYT?
Marek
6 years, 2 months
NPE in keycloak logs in MetricsEventListener
by David Martin
@Jose, @Peter,
sharing this on the lists in case anyone else comes across it (I came
across it while chatting with Jose on IRC).
I also see successful events being logged in keycloak and getting
through to prometheus & the grafana dashboard.
17:12:49,764 ERROR [org.keycloak.events.EventBuilder] (default
task-75) Failed to send type to
org.jboss.aerogear.keycloak.metrics.MetricsEventListener@535339d3:
java.lang.NullPointerException
Full logs & stack
https://gist.github.com/david-martin/430709202e4064fe49e6df139380bd2d
Images being used:
aerogearcatalog/keycloak-apb
latest 0a791099254b 4 days ago 669MB
jboss/keycloak-openshift
3.4.3.Final a032ac87a920 5 weeks ago 844MB
aerogearcatalog/metrics-apb
latest 058e78efe352 4 days ago 669MB
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)
6 years, 2 months
