STS REST interface

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

STS REST interface

Dmitry Tsybulka (Contractor)
Hi Community,

In Zurich Insurance we had a task to provide REST interface for STS module.

I tried to use org.apache.cxf.sts.rest.RESTSecurityTokenServiceImpl, but found following issues:
- it is not possible to change path;
- issue with providing realm name as path param;
- not possible to provide Json-like responses;
- there is no OpenAPI documentation;
- there is no any flexibility with custom functionality.

Because of points above, we implemented own interface and implementation (based on org.apache.cxf.sts.rest.RESTSecurityTokenServiceImpl) that solved all issues that I mentioned.
This is why we propose to contribute our implementation to CXF.
It could be done in following steps steps:
1. For re-using RESTSecurityTokenServiceImpl? implementation and not implements RESTSecurityTokenService, I need to have methods:
    public void setMessageContext(MessageContext messageContext)
    public void setSecurityContext(SecurityContext securityContext)

2. Provide API
- interface with OpenAPI documentation
- requests classes

3.  Provide ContainerRequestFilter and fix in UriRealmParser? for properly manage realm name path parameter.
Provide class ExtRealmProperties for extending realm properties with RS security properties.

4. Provide JaasAuthenticationFilter and JwtAuthenticationFilter

5. Provide new REST interface implementation


Could you please let me know what do you think and, if it is interesting for community, I will provide PRs.

Best Regards,
Dmitry


**************************************
Reply | Threaded
Open this post in threaded view
|

RE: STS REST interface

Andrei Shakirin-2
Hi Dmitry,

Thanks for your efforts and investigations, I appreciate your contribution.
Could you describe a bit more what do you mean under
- "it is not possible to change path"
- "issue with providing realm name as path param"
- "there is no any flexibility with custom functionality"
?

Update methods to public isn't a problem.
Regarding the rest steps: could you please create CXF Jira issue describing current issues and limitations you find?
Then you can provide PRs in context of this Jira.

Regards,
Andrei.

-----Original Message-----
From: Dmitry Tsybulka (Contractor) <[hidden email]>
Sent: Dienstag, 17. September 2019 21:13
To: [hidden email]
Cc: Evgeny Sitnikov <[hidden email]>
Subject: STS REST interface


Warning! External email. Exercise caution when opening attachments or clicking any links.


Hi Community,

In Zurich Insurance we had a task to provide REST interface for STS module.

I tried to use org.apache.cxf.sts.rest.RESTSecurityTokenServiceImpl, but found following issues:
- it is not possible to change path;
- issue with providing realm name as path param;
- not possible to provide Json-like responses;
- there is no OpenAPI documentation;
- there is no any flexibility with custom functionality.

Because of points above, we implemented own interface and implementation (based on org.apache.cxf.sts.rest.RESTSecurityTokenServiceImpl) that solved all issues that I mentioned.
This is why we propose to contribute our implementation to CXF.
It could be done in following steps steps:
1. For re-using RESTSecurityTokenServiceImpl? implementation and not implements RESTSecurityTokenService, I need to have methods:
    public void setMessageContext(MessageContext messageContext)
    public void setSecurityContext(SecurityContext securityContext)

2. Provide API
- interface with OpenAPI documentation
- requests classes

3.  Provide ContainerRequestFilter and fix in UriRealmParser? for properly manage realm name path parameter.
Provide class ExtRealmProperties for extending realm properties with RS security properties.

4. Provide JaasAuthenticationFilter and JwtAuthenticationFilter

5. Provide new REST interface implementation


Could you please let me know what do you think and, if it is interesting for community, I will provide PRs.

Best Regards,
Dmitry


**************************************
As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our contacts privacy notice at Talend, Inc. <https://www.talend.com/contacts-privacy-policy/>