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