6:43 p.m.
Looking at the keycloak source code to see how NameID value is set in the
SAML response, we came across SamlProtocol class that has the following
method:
protected String getNameId(String nameIdFormat, ClientSessionModel
clientSession, UserSessionModel userSession) {
if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get()))
{
return userSession.getUser().getEmail();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get()))
{
// "G-" stands for "generated" Add this for the slight
possibility of collisions.
return "G-" + UUID.randomUUID().toString();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_PERSISTENT.get()))
{
return getPersistentNameId(clientSession, userSession);
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_UNSPECIFIED.get()))
{
// TODO: Support for persistent NameID (pseudo-random
identifier persisted in user object)
return userSession.getUser().getUsername();
} else {
return userSession.getUser().getUsername();
}
}
which is just returning either email or username because of which we are
restricted in the value that can be set for the NameID. We are not able to
set NameID to any value other than this. With our customers, we have seen
lot of cases where users have different IDs across SPs. With the current
implementation in KeyCloak, it seems we can only return Name or Email as
NameID. Ideally in case of “Unspecified” format, we should have a mechanism
to map Name ID to any of user property/attribute. Do you have any plans to
add support for this use case?
With regard to solving this problem, one option could be to implement a
protocol mapper that can be used to map any user property/attribute to
NameID. Currently protocol mapper can only be used to return
saml:Attribute, so writing a new protocol mapper specifically for
requesting NameID would be useful. Is this feasible? And, do you have any
plans to add support for this usecase?
If you are not planning to implement this, are there any design or
implementation level inputs/help you can provide on this? And if we
implement this protocol mapper from our side, would it be possible to merge
it back to the master branch?
7:25 a.m.
Good feedback. We'll eventually open up the protocol mapper spi so that
the entire assertion can be modified.
On 9/11/16 7:43 PM, Rashmi Singh wrote:
Looking at the keycloak source code to see how NameID value is set in
the SAML response, we came across SamlProtocol class that has the
following method:
protected String getNameId(String nameIdFormat,
ClientSessionModel clientSession, UserSessionModel userSession) {
if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get())) {
return userSession.getUser().getEmail();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_TRANSIENT.get()))
{
// "G-" stands for "generated" Add this for the slight
possibility of collisions.
return "G-" + UUID.randomUUID().toString();
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_PERSISTENT.get()))
{
return getPersistentNameId(clientSession, userSession);
} else if
(nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_UNSPECIFIED.get()))
{
// TODO: Support for persistent NameID (pseudo-random
identifier persisted in user object)
return userSession.getUser().getUsername();
} else {
return userSession.getUser().getUsername();
}
}
which is just returning either email or username because of which we
are restricted in the value that can be set for the NameID. We are not
able to set NameID to any value other than this. With our customers,
we have seen lot of cases where users have different IDs across SPs.
With the current implementation in KeyCloak, it seems we can only
return Name or Email as NameID. Ideally in case of “Unspecified”
format, we should have a mechanism to map Name ID to any of user
property/attribute. Do you have any plans to add support for this use
case?
With regard to solving this problem, one option could be to implement
a protocol mapper that can be used to map any user property/attribute
to NameID. Currently protocol mapper can only be used to return
saml:Attribute, so writing a new protocol mapper specifically for
requesting NameID would be useful. Is this feasible? And, do you have
any plans to add support for this usecase?
If you are not planning to implement this, are there any design or
implementation level inputs/help you can provide on this? And if we
implement this protocol mapper from our side, would it be possible to
merge it back to the master branch?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:10 a.m.
Bill, this suggestion is related to my previous post where I was inquiring
if there is a way to edit NameID in Saml response:
http://lists.jboss.org/pipermail/keycloak-dev/2016-September/008027.html
We have a need to implement this protocol now. Assuming that you are
considering adding this feature sometime in future, would you be able to
guide us on how we can implement this now at our end? And if we can
implement this now, will we be able to merge it to the master branch? Any
guidance you can provide on how we can implement this ourselves at this
time would be very useful. Thank you!
On Mon, Sep 12, 2016 at 7:25 AM, Bill Burke <bburke(a)redhat.com> wrote:
Good feedback. We'll eventually open up the protocol mapper spi
so that
the entire assertion can be modified.
On 9/11/16 7:43 PM, Rashmi Singh wrote:
Looking at the keycloak source code to see how NameID value is set in the
SAML response, we came across SamlProtocol class that has the following
method:
protected String getNameId(String nameIdFormat, ClientSessionModel
clientSession, UserSessionModel userSession) {
if (nameIdFormat.equals(JBossSAMLURIConstants.NAMEID_FORMAT_EMAIL.get()))
{
return userSession.getUser().getEmail();
} else if (nameIdFormat.equals(JBossSAML
URIConstants.NAMEID_FORMAT_TRANSIENT.get())) {
// "G-" stands for "generated" Add this for the slight
possibility of collisions.
return "G-" + UUID.randomUUID().toString();
} else if (nameIdFormat.equals(JBossSAML
URIConstants.NAMEID_FORMAT_PERSISTENT.get())) {
return getPersistentNameId(clientSession, userSession);
} else if (nameIdFormat.equals(JBossSAML
URIConstants.NAMEID_FORMAT_UNSPECIFIED.get())) {
// TODO: Support for persistent NameID (pseudo-random
identifier persisted in user object)
return userSession.getUser().getUsername();
} else {
return userSession.getUser().getUsername();
}
}
which is just returning either email or username because of which we are
restricted in the value that can be set for the NameID. We are not able to
set NameID to any value other than this. With our customers, we have seen
lot of cases where users have different IDs across SPs. With the current
implementation in KeyCloak, it seems we can only return Name or Email as
NameID. Ideally in case of “Unspecified” format, we should have a mechanism
to map Name ID to any of user property/attribute. Do you have any plans to
add support for this use case?
With regard to solving this problem, one option could be to implement a
protocol mapper that can be used to map any user property/attribute to
NameID. Currently protocol mapper can only be used to return
saml:Attribute, so writing a new protocol mapper specifically for
requesting NameID would be useful. Is this feasible? And, do you have any
plans to add support for this usecase?
If you are not planning to implement this, are there any design or
implementation level inputs/help you can provide on this? And if we
implement this protocol mapper from our side, would it be possible to merge
it back to the master branch?
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3044
days inactive
3046
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
Rashmi Singh