search

JanssenProject / jans

An open source enterprise digital identity platform for CIAM or workforce... Janssen is a distribution of standards-based, developer friendly, components that are engineered to work together in any cloud. #OAuth #OpenID #FIDO
https://docs.jans.io
Apache License 2.0
471 stars 75 forks source link

feat: add SIOPv2 RP #1185

Open zbrumen opened 2 years ago

zbrumen commented 2 years ago

Description

Prepare

Identified code changes

A lot of changes will be added, this are only the high-level changes, that nclude many sub changes. With discussion, the changes will be changed/added and tasks will then evolve from them.

Test cases and code coverage

Document the changes

ossdhaval commented 2 years ago

Issue title: To make it compliant with Conventional Commits v1.0.0, use add instead of Add in title

zbrumen commented 2 years ago

Changed the endpoint, that need to be implemented, and added all of currently known endpoints. The discussion on how to handle client authentication, once response has been validated from SIOP, is still a discussion, since credentials could be diffrent from the same user. Perhaps a common credential should always be available (like email) ?

ossdhaval commented 2 years ago

Bringing in @yuriyz @moabu for their opinion.

yuriyz commented 2 years ago

re: credentials. Are we talking about client credentials? Yes, it is different for each RP. What is the idea of common credentials? Links to spec or idea explanation would help to understand.

zbrumen commented 2 years ago

re: credentials. Are we talking about client credentials? Yes, it is different for each RP. What is the idea of common credentials? Links to spec or idea explanation would help to understand.

Spec for Verifiable Presentation

the problem is as follows, in SIOP flow we request from the user his verifiable credentials via vp_token (verifiable presentation token). Depending on the implementation of SIOP, their credentials can have certain diffrences in them. (The end-user of the server writes a request with claims, to what you are requesting from the user, certain claims can be constantly changing), the idea of a common credential would be, that we recieve a credential from the client, with which we would be able to identify the client within jans.

My question is, in the current implementation of OIDC, jans probably has an email or something, to identify, which client has authenticated. In the case of SIOP, the server could request information, that has 0 identifying credentials, which would result in a new user being created for each login. (in the case, that the credential would only be a credit card, and when the user changes credit cards, we would create a new user for that same credit card).

Also a nice presentation, of how SIOP flow works: SIOPv2 Spec

ossdhaval commented 2 years ago

Migrated Žiga's question on Gitter related to implementation:

I see, one more question. I've been looking at the code this week, and I have found most of the 
implementations of OpenID for OP. Does jans support OpenID RP (Relying Party) ? 
For SIOP, this would need to be implemented server-side. 
If it already exists on jans, I would appreciate a pointer, where I could find the implementation :) I
'll update the issue on github in case there is none, as I believe it would be beneficial for jans to support SIOP RP as well :)
yuriyz commented 2 years ago
  1. We have client which can call AS APIs here: https://github.com/JanssenProject/jans/tree/main/jans-auth-server/client
  2. For RP we have jans-client-api which makes RP implementation much easier https://github.com/JanssenProject/jans/tree/main/jans-client-api

There is important note about jans-client-api, it is based on dropwizard. We are now in process of migrating jans to jetty 11 (jakarta). Latest dropwizard does not have jakarta based version thus @jmunozherbas (with @duttarnab help) is going to move it to Weld/resteasy and remove dropwizard.

zbrumen commented 2 years ago

About the second point, I should then try to implement RP in the client-api ? I'm asking, since SIOP and SSI add verifiable_presentations. In the old flow, the RP was used to make a authorize request to the OP. But in SIOP, RP is on server-side and you call an API of RP to generate the request for a verifiable presentation, that is then transfered to SIOP (mobile or server) via API call or via URL link (which can be transformed into a QR code on a website).

Soo instead of RP being a client, that communicates with OP to get authenticated, in SIOP, it is a server, that provides API calls that return a JSON, of what type of credentials are being requested (verifiable presentation) and a verification endpoint, that verifies if id_token and vp_token (verifiable presentation response) are "legit". Now the implementation of HOW the verification takes place is still not completly defined and will most likely be "defined per use case", but the whole scenario, of RP being server side and providing a few extra API calls, makes me believe that this new SIOP RP should be in auth-server?

yuriyz commented 2 years ago

If look to protocol flow SI RP still calls SI OP https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#name-protocol-flow

jans-client-api is server as well, so in my understanding SIRP goes to jans-client-api and SIOP to jans-auth-server. So we have clear separation of parties.

I think we need @nynymike opinion on it.

nynymike commented 2 years ago

If you need the RP to be a server, then jans-client-api makes a lot of sense to me...

You can view the swagger for jans-client-api here

zbrumen commented 2 years ago

I see, OK, this is starting to make more sense to me now thank you! :D

I'll try to update and upgrade the RP endpoints, to support SIOP flow.

I'll also update the tasks above, what has to be done :)