Skip to content

The third alpha release

Pre-release
Pre-release
Compare
Choose a tag to compare
@jalauros jalauros released this 20 Jun 11:48
· 504 commits to master since this 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.