Hi Vjacheslav,
Thanks for your interest and question.
Basically STS Service is not required, it is just an option. Of course you can
issue SAML Token directly by the client.
However, there are some cases where STS can be useful (I have also written them
in the post):
1) Federation scenario with multiple clients from different domains sending
requests to the same target service
In this case if every client issues SAML itself, the target service have
to trust all clients certificates. This is complex administration task
(certificates are expired, etc) and even not allowed in some cases because of
security restrictions.
This problem is solved by using STS Service, because in this case target
service have to trust only STS certificate. STS cares about client
authentication, PoP, etc.
2) If you use different types of tokens and authentication methods the client
should be aware and care about all of them.
STS helps to resolve that, because client just delegates PoP and Token
issuing tasks to STS service. Client dependencies, configuration and code stay
lean.
Regards,
Andrei.
> -----Original Message-----
> From: Vjacheslav V. Borisov [mailto:[email protected]]
> Sent: Donnerstag, 31. März 2016 10:39
> To: [email protected]
> Subject: Re: Post: CXF JAX-RS SAML based authentication
>
> Hi!
>
> Interesting article, but if we are using client private and public keys in SSL
> connection, why additional STS service is required?
>
>
> 2016-03-30 23:21 GMT+04:00 Andrei Shakirin <[email protected]>:
>
> > Hi,
> >
> > I have published a small post with example illustrating JAX-RS SAML
> > based authentication using new STSTokenOutInterceptor:
> >
> > http://ashakirin-cxf-security.blogspot.de/2016/03/cxf-jax-rs-security-
> > authentication-with.html
> >
> > Perhaps can help somebody interesting JAX-RS security in CXF.
> >
> > Regards,
> > Andrei.
> >
