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) < [email protected]> 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: '[email protected]' > 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
