1.1.1

Fixes

ClientInformationResolvers are prematurely expiring cached keys #34
Redirect URI validation possibly throwing NPE #35
Configuration property for client secret expiration not wired #36
Claims stored to authorization code not set to access tokens #43

Features

See v1.1.0 release notes for the list of features.

Installation

The installation process is described in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive.

Updating from v1.1.0

• Stop your Shibboleth IdP
• Make a backup copy of your Shibboleth IdP home directory.
• Remove directories flows/oidc and copy the corresponding folder with its subdirectories from the distribution archive.
  • The files flows/oidc/token/token-beans.xml and flows/oidc/register/register-beans.xml have changed.
• Copy edit-webapp/WEB-INF/lib contents from the archive to replace the current edit-webapp/WEB-INF/lib contents
• Remove v1.1.0 binaries and their older duplicate dependencies (from edit-webapp/WEB-INF/lib) before rebuilding the war.
  • At least the following JAR files may contain multiple versions, make sure that only the latest version exists:
    • idp-oidc-extension-api-1.*
    • idp-oidc-extension-impl-1.*
    • nimbus-jose-jwt-8.*
• Rebuild Shibboleth IdP.
• Start Shibboleth IdP.

Updating from v1.0.x

• Stop your Shibboleth IdP

• Make a backup copy of your Shibboleth IdP home directory.

• The conf/oidc-relying-party.xml file MUST be updated

  • If you have not modified the file previously, you can copy the new version from the distribution archive over the existing file.
  • If the file contains your modifications, the following changes existing in the distribution archive conf/oidc-relying-party.xml file need to be merged:
    • OIDC.SSO bean definition has two new parameters: p:forcePKCE and p:allowPKCEPlain
    • OAUTH2.Introspection bean (bean id="OAUTH2.Introspection") definition has been added

• The following two new configuration properties may be set in conf/idp-oidc.properties. Examples are shown in distribution archive conf/idp-oidc.properties file

  • idp.oidc.forcePKCE and idp.oidc.allowPKCEPlain, both defaulting to false.

• Remove directories flows/oidc and flows/oauth2, and copy the corresponding folders from the distribution archive. The contents of both directories have changed.

• Copy edit-webapp/WEB-INF/lib contents from the archive to replace the current edit-webapp/WEB-INF/lib contents

• Remove v1.0.x binaries and their dependencies (from edit-webapp/WEB-INF/lib) before rebuilding the war.

  • At least the following JAR files may contain multiple versions, make sure that only the latest version exists:
    • gson-2.8.*
    • idp-oidc-extension-api-1.*
    • idp-oidc-extension-impl-1.*
    • nimbus-jose-jwt-8.*

• Rebuild Shibboleth IdP.

• Start Shibboleth IdP.

1.1.0

Fixes

Client-side storage of user sessions failing #24
Client information storing logging levels #28
Matchers should return empty for null #29

Features

• PKCE - See OIDC.SSO profile configuration documentation for the forcePKCE and allowPKCEPlain options.
• OAuth2 Token Introspection - See OAUTH2.Introspection profile configuration documentation.

The open source license has been changed to Apache 2.0

See v1.0.0 release notes for the previously existing features.

Installation

The installation process is described in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive.

Updating from v1.0.x

• Stop your Shibboleth IdP

• Make a backup copy of your Shibboleth IdP home directory.

• The conf/oidc-relying-party.xml file MUST be updated

  • If you have not modified the file previously, you can copy the new version from the distribution archive over the existing file.
  • If the file contains your modifications, the following changes existing in the distribution archive conf/oidc-relying-party.xml file need to be merged:
    • OIDC.SSO bean definition has two new parameters: p:forcePKCE and p:allowPKCEPlain
    • OAUTH2.Introspection bean (bean id="OAUTH2.Introspection") definition has been added

• The following two new configuration properties may be set in conf/idp-oidc.properties. Examples are shown in distribution archive conf/idp-oidc.properties file

  • idp.oidc.forcePKCE and idp.oidc.allowPKCEPlain, both defaulting to false.

• Remove directories flows/oidc and flows/oauth2, and copy the corresponding folders from the distribution archive. The contents of both directories have changed.

• Copy edit-webapp/WEB-INF/lib contents from the archive to replace the current edit-webapp/WEB-INF/lib contens

• Remove v1.0.x binaries and their dependencies (from edit-webapp/WEB-INF/lib) before rebuilding the war.

  • At least the following JAR files may contain multiple versions, make sure that only the latest version exists:
    • gson-2.8.*
    • idp-oidc-extension-api-1.*
    • idp-oidc-extension-impl-1.*

• Rebuild Shibboleth IdP.

• Start Shibboleth IdP.

1.0.2

Fixes

Claims parameter parsed incorrectly when in request object #21
(Invalid) logo in client metadata causes NPE #20
NPE when disabled OIDC.Configuration or OIDC.Keyset flows are called #18
Removed erroneous bean close tag #15

Features

See v1.0.0.

Installation

The installation process is described in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive.

Updating from v1.0.0 and v1.0.1

• Replace /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/idp-oidc-extension-api-1.0.x.jar with idp-oidc-extension-api-1.0.2.jar from the archive.
• Replace /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/idp-oidc-extension-impl-1.0.x.jar with idp-oidc-extension-impl-1.0.2.jar from the archive.
• Replace /opt/shibboleth-idp/flows/oidc/abstract-api-info/oidc-abstract-api-info-flow.xml with oidc-abstract-api-info-flow.xml from the archive.
• Rebuild and Restart Shibboleth IdP.

1.0.1

Fixes

Kid missing from JWE header #16.

Features

See v1.0.0.

Installation

The installation process is described in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive.

Updating from v1.0.0

• Replace /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/idp-oidc-extension-api-1.0.0.jar with idp-oidc-extension-api-1.0.1.jar from the archive.
• Replace /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/idp-oidc-extension-impl-1.0.0.jar with idp-oidc-extension-impl-1.0.1.jar from the archive.
• Rebuild and Restart Shibboleth IdP.

1.0.0

Features

Dynamic Registration

Related specification: https://openid.net/specs/openid-connect-registration-1_0.html

• List of verified & stored claims
  • scope
  • redirect_uris
  • application_type
  • contacts
  • response_types
  • grant_types (implicit, authorization_code, refresh_token)
  • subject_type
  • jwks and jwks_uri
  • token_endpoint_auth_method
  • logo_uri
  • policy_uri
  • tos_uri
  • userinfo_signed_response_alg
  • client_secret generation & storage in plaintext
• Only “open registration” currently supported (the RPs are not authenticated in any way)
  • Use “shibboleth.UnverifiedRelyingParty" -bean in relying-party.xml

OP Discovery

Related specification: https://openid.net/specs/openid-connect-discovery-1_0.html

Flow flows/oidc/webfinger contains simplified WebFinger implementation that always responds with the requested resource without any kind of verification.

Flow flows/oidc/discovery contains building blocks to dynamically build desired set of the openid-configuration claims on top of static file.

Token Revocation

See https://tools.ietf.org/html/rfc7009.

Authorization, Token and UserInfo endpoints

Related specification: http://openid.net/specs/openid-connect-core-1_0.html

• response types supported

  • code
  • id_token
  • token id_token
  • code id_token
  • code token
  • code token id_token

• subject types supported

  • public
  • pairwise

• response_modes_supported

  • query
  • fragment
  • form_post

• grant types supported

  • authorization_code
  • implicit
  • refresh_token

• claims parameter supported

• request parameter supported

• request_uri parameter supported

• id token encryption and signing supported

• userinfo response encryption and signing supported

• request object decryption and signature validation supported. Algorithm "none" may be used if registered for the client.

Algorithms supported are:

• encryption 'alg' values supported

  • RSA1_5
  • RSA-OAEP
  • RSA-OAEP-256
  • A128KW
  • A192KW
  • A256KW

• encryption 'enc' values supported

  • A128CBC-HS256
  • A192CBC-HS384
  • A256CBC-HS512
  • A128GCM
  • A192GCM
  • A256GCM

• signing 'alg' values supported

  • RS256
  • RS384
  • RS512
  • HS256
  • HS384
  • HS512
  • ES256
  • ES384
  • ES512

• token endpoint auth methods supported

  • client_secret_basic
  • client_secret_post
  • client_secret_jwt
  • private_key_jwt

Installation

The installation process is decribed in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-from-archive. You may use the provided Ansible scripts to deploy a Vagrant VM for your testing purposes.

Feedback

We are following shibboleth users and developers list. Please use that for support requests. When you encounter a bug or have a request for feature you may enter it to GitHub project as an issue.

The first beta release

Features

Dynamic Registration

Related specification: https://openid.net/specs/openid-connect-registration-1_0.html

• List of verified & stored claims
  • scope
  • redirect_uris
  • application_type
  • contacts
  • response_types
  • grant_types (implicit, authorization_code, refresh_token)
  • subject_type
  • jwks and jwks_uri
  • token_endpoint_auth_method
  • logo_uri
  • policy_uri
  • tos_uri
  • userinfo_signed_response_alg
  • client_secret generation & storage in plaintext
• Only “open registration” currently supported (the RPs are not authenticated in any way)
  • Use “shibboleth.UnverifiedRelyingParty" -bean in relying-party.xml

OP Discovery

Related specification: https://openid.net/specs/openid-connect-discovery-1_0.html

Flow flows/oidc/webfinger contains simplified WebFinger implementation that always responds with the requested resource without any kind of verification.

Flow flows/oidc/discovery contains building blocks to dynamically build desired set of the openid-configuration claims. The default configuration uses the contents of a static file.

Token Revocation

New endpoint. See https://tools.ietf.org/html/rfc7009.

Authorization, Token and UserInfo endpoints

Related specification: http://openid.net/specs/openid-connect-core-1_0.html

• response types supported

  • code
  • id_token
  • token id_token
  • code id_token
  • code token
  • code token id_token

• subject types supported

  • public
  • pairwise

• response_modes_supported

  • query
  • fragment
  • form_post

• grant types supported

  • authorization_code
  • implicit
  • refresh_token

• claims parameter supported

• request parameter supported

• id token encryption alg values supported (*)

  • RSA1_5

• id_token encryption enc values supported (*)

  • A128CBC-HS256

• id token signing alg values supported

  • RS256
  • RS384
  • RS512
  • HS256
  • HS384
  • HS512
  • ES256
  • ES384(**)
  • ES512(**)

• userinfo encryption alg values supported (*)

  • RSA1_5

• userinfo encryption enc values supported (*)

  • A128CBC-HS256

• userinfo signing alg values supported

  • RS256
  • RS384
  • RS512
  • HS256
  • HS384
  • HS512
  • ES256
  • ES384(**)
  • ES512(**)

• request object signing alg values supported

  • none
  • RS256
  • RS384
  • RS512
  • HS256
  • HS384
  • HS512
  • ES256
  • ES384
  • ES512

• token endpoint auth methods supported

  • client_secret_basic
  • client_secret_post
  • client_secret_jwt
  • private_key_jwt

Known shortcomings:.

• Not signing id token is not supported (i.e. algorithm NONE).
• Request object encryption is not supported. Will be added before first production release.
• Aggregated claims are not supported.
• Distributed claims are not supported.
• (*) The list of supported key transport and encryption algorithms is short and will be improved for first production release
• (**) Not supported by default installation. Beta release has limitation of supporting only one ES family of signing algorithm per security configuration.

Installation

The recommended way to test beta release is to install it on top of existing Shibboleth IdP 3.4+ installation. The installation process is decribed in https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki/Installing-v0.8.0b-release-from-archive. You may still use the Ansible scripts to deploy a Vagrant VM.

Feedback

We are following shibboleth developers list. Please use that for support requests. When you encounter a bug or have a request for feature you may enter it to GitHub project as an issue.

The third alpha release

Features

Dynamic Registration

Related specification: https://openid.net/specs/openid-connect-registration-1_0.html

• List of verified & stored claims
  • scope
  • redirect_uris
  • application_type
  • contacts
  • response_types
  • grant_types (implicit, authorization_code, refresh_token)
  • subject_type
  • jwks and jwks_uri
  • token_endpoint_auth_method
  • logo_uri
  • policy_uri
  • tos_uri
  • userinfo_signed_response_alg
  • client_secret generation & storage in plaintext
• Only “open registration” currently supported (the RPs are not authenticated in any way)
  • Use “shibboleth.UnverifiedRelyingParty" -bean in relying-party.xml

OP Discovery

Related specification: https://openid.net/specs/openid-connect-discovery-1_0.html

Flow flows/oidc/webfinger contains simplified WebFinger implementation that always responds with the requested resource without any kind of verification.

Flow flows/oidc/discovery contains building blocks to dynamically build desired set of the openid-configuration claims. The default configuration uses the contents of a static file.

Authorization, Token and UserInfo endpoints

Related specification: http://openid.net/specs/openid-connect-core-1_0.html

Main changes to v0.6.0a:

• Attribute encoders have a new flag setToToken. Setting this true indicates the attribute not to be resolvable in Token/UserInfo endpoints and that it should be carried in tokens. See Wiki for details.
• The default policy of encoding user claims to both id token and userinfo response has changed. By default user attributes are now encoded only to userinfo response unless response type is “id_token”. There are new attribute encoder flags placeToIDToken and denyUserInfo for deviating from default behaviour. See Wiki for details.
• Information of consentable and consented claims is now applied also in token and userinfo endpoints.
• Grant type “refresh_token” is now supported. Redefining scope is also supported when doing the refresh.
• Userinfo responses are now signed if client has registered a acceptable algorithm.

Known shortcomings of which most still need to be addressed.

• There is no token revocation endpoint.
• There is no mechanism to populate multiple audiences. Value of “aud” is always client_id and nothing else. Also as related to that defining “azp” is not supported. May of course be set by attribute resolving mechanism.
• “amr” is not supported.
• Encryption is not supported.
• Not signing id token is not supported (i.e. algorithm NONE).
• prompt=consent is not supported.
• Id_token_hint not supported.
• Request object is not supported.
• Userinfo endpoint is not checking for “user presence” as the specification suggests.
• Scope “offline_access” is not supported. Well, see previous.
• Signing using HS family of algorithms is crippled. The key used should be client secret and with current implementation that is not possible to configure.
• Aggregated claims are not supported.
• Distributed claims are not supported.
• If prompt is set to ‘none’, user may still be presented with attribute release content page
• Support for more complex claims needs also to be still addressed.

Installation

The recommended way to test alpha release is to deploy it using the provided ansible scripts to vagrant. You may edit the script to install it to cloud or install it manually on top of existing shibboleth idp test installation but the support for doing that will be very limited from us. We are interested in hearing on your experiences though if you choose to go that way.

Vagrant deployment is described on https://github.com/CSCfi/shibboleth-idp-oidc-extension
_Tested with Vagrant versions 1.9.5 & 2.0.1 & 2.1.1
_Tested with Ansible version 2.3.0 & 2.4.1 & 2.5.5

Feedback

Feedback is preferred in the form of GitHub issues if applicable.

• We would like to hear about oidc conformance
• We would like to hear about configuring oidc
  • The alpha release already should be very shibboleth like when it comes to configuring it, it should not feel like something glued on top of it. If you find that configuring oidc extension is not what you would expect, we would like to hear about it. The configuration options are described in the wiki https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki
• Bugs in general
  • We have not intentionally left any bugs for you to find. If you find any, we would like to hear about it.
• Installation
  • Installation has not been yet on our focus and we understand this alpha release will not reflect final product on that area. It is however interesting to hear if you have a view on how the installation should be done.

Second alpha release

Features

Dynamic Registration

Related specification: https://openid.net/specs/openid-connect-registration-1_0.html

• List of verified & stored claims
  • scope
  • redirect_uris
  • application_type
  • contacts
  • response_types
  • grant_types (implicit, authorization_code, refresh_token)
  • subject_type
  • jwks and jwks_uri
  • token_endpoint_auth_method
  • logo_uri
  • policy_uri
  • tos_uri
  • client_secret generation & storage in plaintext
• Only “open registration” currently supported (the RPs are not authenticated in any way)
  • Use “shibboleth.UnverifiedRelyingParty" -bean in relying-party.xml

Webfinger

Related specification: https://openid.net/specs/openid-connect-discovery-1_0.html

Flow /oidc/webfinger contains simplified WebFinger implementation that always responds with the requested resource without any kind of verification.

Authorization and Token endpoints

Related specification: http://openid.net/specs/openid-connect-core-1_0.html#Authentication

New features since v0.5.0a:

• New supported response types are “code”, “token id_token”, “code id_token”, “code token” and “code token id_token”. Supported response types cover now all implicit, authorization code and hybrid types.
• Authorization Code and Access Token are themselves completely stateless. There is however replay and revocation caches for them that need to be taken into account in clustering.
• Authorization endpoint populates some OIDC metadata fields to RpUIContext that can be rendered for instance in the login view
• New Token endpoint. Token endpoint supports all client authentication methods “client_secret_basic”, “client_secret_post”, “client_secret_jwt” and “private_key_jwt”.

Known shortcomings / features not yet supported. List is not comprehensive.

• Request object is not supported
• Grant type “refresh_token” is not supported
• Encryption of ID Token is not supported
• Prompt values ‘consent’ and ‘select_account’ are ignored.
• If prompt is set to ‘none’, user may still be presented with attribute release content page

UserInfo endpoint

Related specification: http://openid.net/specs/openid-connect-core-1_0.html#UserInfo

• UserInfo endpoint introduced in this release has own profile configuration that may be disabled in relying party configuration.
• Releases claims based on attribute filtering of the original authentication request. Claim splitting between ID Token and UserInfo endpoints is supported.

Known shortcomings / features not yet supported. List is not comprehensive.

• Encryption and Signing of the response is not supported

Installation

The recommended way to test alpha release is to deploy it using the provided ansible scripts to vagrant. You may edit the script to install it to cloud or install it manually on top of existing shibboleth idp test installation but the support for doing that will be very limited from us. We are interested in hearing on your experiences though if you choose to go that way.

Vagrant deployment is described on https://github.com/CSCfi/shibboleth-idp-oidc-extension
Tested with Vagrant versions 1.9.5 & 2.0.1
Tested with Ansible version 2.3.0 & 2.4.1

Feedback

Feedback is preferred in the form of GitHub issues if applicable.

• We would like to hear about oidc conformance
• We would like to hear about configuring oidc
  • The alpha release already should be very shibboleth like when it comes to configuring it, it should not feel like something glued on top of it. If you find that configuring oidc extension is not what you would expect, we would like to hear about it. The configuration options are described in the wiki https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki
• Bugs in general
  • We have not intentionally left any bugs for you to find. If you find any, we would like to hear about it.
• Installation
  • Installation has not been yet on our focus and we understand this alpha release will not reflect final product on that area. It is however interesting to hear if you have a view on how the installation should be done.

The first alpha release

Features

Dynamic Registration

Related specification: https://openid.net/specs/openid-connect-registration-1_0.html

• List of verified & stored claims
  • scope
  • redirect_uris
  • application_type
  • contacts
  • response_types (id_token)
  • grant_types (implicit)
• Only “open registration” currently supported (the RPs are not authenticated in any way)
  • Use “shibboleth.UnverifiedRelyingParty" -bean in relying-party.xml

WebFinger

Related specification: https://openid.net/specs/openid-connect-discovery-1_0.html

Flow flows/oidc/webfinger contains simplified WebFinger implementation that always responds with the requested resource without any kind of verification.

Authorize flow

Related specification: http://openid.net/specs/openid-connect-core-1_0.html

• Supported response type is “id_token”.

• Features exceeding the minimum behaviour required for conformance. List is not comprehensive.

  • ID Tokens may be signed with any oidc signing algorithm, not just RS256
  • Acr may be requested both as voluntary and essential claim
  • Subject types public and pairwise are both supported
  • Claims parameter is supported

• Known shortcomings / features not supported. List is not comprehensive.

  • Prompt values ‘consent’ and ‘select_account’ are ignored.
  • If prompt is set to ‘none’, user may still be presented with attribute release consent page
  • Encryption of ID Token is not supported
  • Request object is not supported

Noncomprehensive list of General OIDC extension related features

• As an addition to conventional shibboleth credentials, JWK based credentials are also supported.
• Attribute filtering has two extensions:
  • Policy rule oidcext:OIDCScope for requested scope.
  • Matcher oidcext:AttributeInOIDCRequestedClaims for requested claim.
• Attribute Encoder extensions
  • oidcext:OIDCString
  • oidcext:OIDCScopedString
  • oidcext:OIDCByte
• Signing configuration extensions supporting RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512 signature algorithms.

Installation

The recommended way to test alpha release is to deploy it using the provided ansible scripts to vagrant. You may edit the script to install it to cloud or install it manually on top of existing shibboleth idp test installation but the support for doing that will be very limited from us. We are interested of hearing on your experiences though if you choose to go that way.

Vagrant deployment is described on https://github.com/CSCfi/shibboleth-idp-oidc-extension

• Tested with Vagrant versions 1.9.5 & 2.0.1
• Tested with Ansible version 2.3.0 & 2.4.1 & 2.4.2

Feedback

Feedback is preferred in the form of GitHub issues if applicable.

• We would like to hear about oidc conformance
  • If the implicit flow is behaving badly we would like to hear about it.
• We would like to hear about configuring oidc
  • The alpha release already should be very shibboleth like when it comes to configuring it, it should not feel like something glued on top of it. If you find that configuring oidc extension is not what you would expect, we would like to hear about it. The configuration options are described in the wiki https://github.com/CSCfi/shibboleth-idp-oidc-extension/wiki
• Bugs in general
  • We have not intentionally left any bugs for you to find. If you find any, we would like to hear about it.
• Installation
  • Installation has not been yet on our focus and we understand this alpha release will not reflect final product on that area. It is however interesting to hear if you have a view on how the installation should be done.