[keycloak-user] SAML Broker in Keycloak 1.2 Snapshot

[Raghu Prabhala]

My apologies. Didn't realize that the xml had references to STS. That is not what we have and as you mentioned, we can ignore them.  Will wait  for the claim mapping from Bill.

Thanks a lot.

Sent from my iPhone

> On Feb 19, 2015, at 12:21 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> ----- Original Message -----
>> From: "Raghu Prabhala" <prabhalar at yahoo.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "Keycloak-user" <keycloak-user at lists.jboss.org>
>> Sent: Thursday, February 19, 2015 2:24:09 PM
>> Subject: Re: [keycloak-user] SAML Broker in Keycloak 1.2 Snapshot
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Feb 19, 2015, at 8:46 AM, Pedro Igor Silva <psilva at redhat.com> wrote:
>>> 
>>> ----- Original Message -----
>>>> From: "Raghu Prabhala" <prabhalar at yahoo.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "Keycloak-user" <keycloak-user at lists.jboss.org>
>>>> Sent: Thursday, February 19, 2015 11:25:24 AM
>>>> Subject: Re: [keycloak-user] SAML Broker in Keycloak 1.2 Snapshot
>>>> 
>>>> Hi Pedro - Please see my comments inline.
>>>> Thanks,Raghu
>>>>       From: Pedro Igor Silva <psilva at redhat.com>
>>>> To: Raghu Prabhala <prabhalar at yahoo.com>
>>>> Cc: Keycloak-user <keycloak-user at lists.jboss.org>
>>>> Sent: Thursday, February 19, 2015 6:33 AM
>>>> Subject: Re: [keycloak-user] SAML Broker in Keycloak 1.2 Snapshot
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Raghu Prabhala" <prabhalar at yahoo.com>
>>>>> To: "Keycloak-user" <keycloak-user at lists.jboss.org>
>>>>> Sent: Thursday, February 19, 2015 12:20:00 AM
>>>>> Subject: [keycloak-user] SAML Broker in Keycloak 1.2 Snapshot
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I tested out the SAML broker functionality that is listed in the below
>>>>> example
>>>>> https://github.com/keycloak/keycloak/tree/master/examples/broker/saml-broker-authentication
>>>>> 
>>>>> We have a very important use case that is similar to the above except
>>>>> that
>>>>> the SAML Identity broker is ADFS and a few issues are preventing me from
>>>>> testing it out:
>>>>> 
>>>>> 1) The ADFS IDP requires that I upload the KC SAML broker information
>>>>> (SAML
>>>>> metadata) which is not available currently. Perhaps I can generate my own
>>>>> metadata using the above example but would prefer KC to provide one that
>>>>> is
>>>>> similar to IDP metadata that is listed in the documentation.
>>>> 
>>>> In this case you need a SPSSODescriptor, right ? I think we can easily
>>>> implement an endpoint to retrieve SP metadata for SAML applications.
>>>> [RAGHU] - Yes. SPSSODescriptor is what I am looking for. Great. Looking
>>>> forward to see it near term.
>>>>> 2) The ADFS IDP metadata has RoleDescriptor element that is not currently
>>>>> being parsed by the KC SAML broker. I logged my issues in the JIRA
>>>>> https://issues.jboss.org/browse/KEYCLOAK-883
>>>> 
>>>> I've already fixed our parsers. However, the RoleDescriptor you have in
>>>> that
>>>> metadata are describing WS-Federation entities that will just be ignored.
>>>> 
>>>> 
>>>> [RAGHU] - Great. Thanks Pedro. Unfortunately all the claims are described
>>>> under RoleDescriptor  - so I will have to build something to handle that.
>>>> Any advice on where I should start?
>>> 
>>> A few questions ...
>>> 
>>> Can you give more details why you need to handle that ?
>> 
>>> [RAGHU] we have a number of windows applications (share point, lync etc)
>>> that make use of AD groups that are sent as a part of the SAML response by
>>> our IDP which is ADFS. There are a number of windows specific attributes
>>> that are described by schemas.microsoft.com as well as schemas.xmlsoap.org
>>> and they have been used under role descriptor element in the IDPSSO. We
>>> need to able parse the metadata and then retrieve the attributes which
>>> should then be passed to the client applications
> 
> Accordingly with the metadata you are using, claims are not defined for the IdP sso descriptor, but for the roledescriptor that references a STS endpoint. That is why I asked you about the STS  and why I think we can safely ignore that for now, considering that we are brokering a SAML IdP and not a STS.
> 

> Given that, I think that what you are missing is Bill's work around claim mapping. Which should be available soon.
> 
> For now, the broker only trust/federate identities from external IdPs in order to create and authenticate the user in KC. Only some basic attributes are considered during federation such as identifier, username, email and first and last name.
> 
>> 
>>> Your use case is about brokering the SAML Identity Provider described by a
>>> idp descriptor along your metadata, right ? Or are you trying to broker a
>>> STS ?
>> [RAGHU] we have a requirement for STS as well but I wanted to get the basic
>> use cases out first and then I will be back with more requirements
> 
> I believe the broker SPI can easily support a WS-Trust STS provider. But today it is not in the list of OOTB providers.
> 
>>>> 
>>>>> 3) The roles and other claims need to passed back to the client
>>>>> applications
>>>>> using OIDC (I am aware that Bill is making some functionality available
>>>>> over
>>>>> the next few days and hopefully it will address my requirement)
>>>>> 
>>>>> Any suggestions on how I handle the first two?
>>>>> 
>>>>> Thanks,
>>>>> Raghu
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>