Re: Customize the Fediz IDP SAML subject NameID

[Colm O hEigeartaigh <co...@apache.org>]

Hi Andreas,

I've made some changes to the SubjectProvider interface and
DefaultSubjectProvider implementation based on your requirements. The
DefaultSubjectProvider functionality is now broken into methods that are
easier to override, if you wish to change which principal is selected, or
how the principal is used to create the Subject, etc. I merged this into
CXF 3.0.x as well. In addition, for CXF 3.1.x I added a new
SubjectProviderParameters Object, which is passed to the SubjectBean,
containing the Assertion Attributes, etc. I don't want to merge this back
to CXF 3.0.x for backwards compatibility reasons. Hopefully this meets your
requirements.

Colm.

On Wed, May 27, 2015 at 12:44 PM, Andreas Vallen <an...@gmail.com>
wrote:

> Hello Colm,
>
> your pointing out of the SubjectProvider is much appreciated, I had managed
> to overlook this interface and its use seems like the right way to go.
>
> Also your suggestion of adding a principal-post-processing template method
> is a good one.
>
> I'd like to add one suggestion: for determining the subject name it will
> frequently be necessary to derive it from some of the other attributes of
> the user, some of which are already known by the invoking
> SAMLTokenProvider. For example the claims of the user might include her
> e-mail address which shall be used for the NameID instead a kerberos
> identifier.
>
> However as the code is structured now, there is no way to get access to
> these attributes from the SubjectProvider. It would be great if those
> attributes could also be provided to the new template method. These could
> include all the user attributes that are already known by the
> SAMLTokenProvider, e.g. via setting the list of attribute-, auth- and
> authz-Statements to the tokenProvider#additionalProperties.
>
> Also it would be good if the method had access to the whole SubjectBean
> instead of only the NameID value, so one can also modify e.g. the
> subjectNameIDFormat property.
>
> Many thanks,
> Andreas
>
>
> 2015-05-27 11:50 GMT+02:00 Colm O hEigeartaigh <co...@apache.org>:
>
> > Hi Andreas,
> >
> > I think right now there is no easily extensible way of doing this. One
> > option is to use a different SubjectProvider implementation (take the
> > DefaultSubjectProvider and modify the principal that is stored in the
> > SubjectBean as required), and plug it into the SAMLTokenProvider.
> >
> > I don't think the IdentityMapper is the best solution, because as you
> said
> > it is really to be used when you have principals in different realms.
> >
> > What I suggest is just to introduce a new method in the
> > DefaultSubjectProvider to transform a principal, which can be overridden
> by
> > a subclass. I think adding a new interface is probably overkill, as the
> > SubjectProvider is itself an interface that can be implemented if
> required.
> > Would this meet your requirements?
> >
> > Colm.
> >
> > On Tue, May 26, 2015 at 8:02 PM, Vallen, Andreas (Ext) <
> > andreas.vallen@novartis.com> wrote:
> >
> > > Hi,
> > >
> > > I already can answer part of the question: it seems the IdentityMapper
> > > abstraction _can_ in fact also be used (better: abused) for mapping the
> > > Principal that is used for the SAML Subject NameID.
> > >
> > > Fediz will trigger this mapping if the token returned from the STS to
> the
> > > IDP does have a different (source-) realm than the target-realm, _and_
> a
> > > relationship is configured that maps one to the other. See
> > > AbstractOperation#processValidToken.
> > >
> > > So for modifying the Subject NameID I could now assign different realms
> > to
> > > the SAML tokens generated by the STS, one realm for the usernametoken
> STS
> > > endpoint, another for the Kerberos STSTransport, and let them both be
> > > converted to a different target realm.
> > >
> > > This however is clearly abusing a facility that is designed for the
> > > classic federation case, because in my setup, there actually are no
> > > different realms in the usual sense of the word, only different
> > > authentication mechanisms.
> > >
> > > So the question remains if I am missing some simpler mechanism for
> > > achieving what I want that can do without introducing synthetic realms.
> > Or
> > > am I mistaken and Fediz equals authentication mechanisms with realms
> and
> > > this is the way to go?
> > >
> > > Andreas
> > >
> > >
> > >
> > >
> > > From: Vallen, Andreas (Ext)
> > > Sent: Dienstag, 26. Mai 2015 15:22
> > > To: 'users@cxf.apache.org'
> > > Subject: Customize the Fediz IDP SAML subject NameID
> > >
> > > Hi,
> > >
> > > In a fediz SSO setup, I want to customize the subject NameID that is
> set
> > > in the SAML assertion of the WS-Federation response. The value shall be
> > > different from the username that is entered in the login form.
> > >
> > > Similarly for the case where I configure kerberos authentication: here
> > the
> > > default is to use the kerberos useridentifier which includes the
> Kerberos
> > > domain name - somthing that the relying parties are not interested in.
> > >
> > > Instead I'd either like to use some mapping in order to transform the
> > > Principal name similar to how it is done inside the ClaimsManager with
> > the
> > > IdentityMapper abstraction. An alternative option would be to be able
> to
> > > configure a claim whose value should be used as the NameID value
> instead.
> > >
> > > I cannot seem to find an extension point that allows one or the other.
> > Can
> > > someone tell if this this possible with fediz or suggest a good
> > workaround
> > > if not?
> > >
> > > Kind Regards,
> > > Andreas
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com